Re: multithreaded debugging

Dean
I think you hit he problem: the kernel should run in order to control the
machine but the interface could be stopped without any problem. Besides
having kernel "ON" helps to better debug interface.
I need to use debug mechanisms because EVC4 doesn't allow me to do. I know
how to debug old real time systems: logging, flags, led messages,
oscilloscope, due to my experience in microcontrollers and PLCs. I thought
Windows CE was better; debugging a thread without interfere with the other
was really powerful, but now with EVC4 it isn't possible anymore and my
opinion is changing.
Thanks
Mauro

"Dean Ramsier" <ramsiernospam@xxxxxxxxxx> ha scritto nel messaggio
news:eu04kGnJGHA.3100@xxxxxxxxxxxxxxxxxxxxxxx
> The only explanation for debugging like this I can think of is if the
> threads are unrelated, but need to keep running. For example, in a
> process control environment where the process can't be stopped. As Chris
> said, if you need to keep the kernel running you need to be using debug
> mechanisms such as logging that don't halt the kernel.
>
> --
> Dean Ramsier - eMVP
> BSQUARE Corporation
>
>
> "<ctacke/>" <ctacke_AT_OpenNETCF_com> wrote in message
> news:e$QnObmJGHA.2012@xxxxxxxxxxxxxxxxxxxxxxx
>> How can you possibly expect to debug like this? If the thread you're
>> debugging relies on the state of other threads (and it must or you
>> wouldn't have this complaint) then the results in debug mode would be
>> invalid. If all other threads continue to run, your thread timings will
>> be totally screwed up. You're going to have deadlocks, timeouts or other
>> strange behavior.
>>
>> You should probably consider log files, posting data to the event viewer,
>> or some other mechanism that doesn't interfere with the threads running.
>>
>> -Chris
>>
>>
>> "Mauro de Gennaro" <mdegennaro@xxxxxxxxxxxxx> wrote in message
>> news:umDkGKmJGHA.2696@xxxxxxxxxxxxxxxxxxxxxxx
>>> Thanks for your answer.
>>> Real world is a bit more complex. WaitForSingleObject time out is not a
>>> constant because it depends on "field" conditions and on other threads
>>> status; it is not a problem to set time out to INFINITE for debugging
>>> reasons but two questions arise:
>>> 1 - why does debugger suspend all threads? In EVC3 only the break"ed"
>>> one was stopped; i wonder if are there any way to avoid this. Changing
>>> time out to INFINITE works around the problem without solve it because
>>> the real time threads are resumed but, cause their inactivities, they
>>> don't work well anymore.
>>> 2 - if debugger suspend all threads why doesn't it suspend time out
>>> computation too?
>>> Mauro
>>>
>>>
>>> "Voidcoder" <voidcoder@xxxxxxxxx> ha scritto nel messaggio
>>> news:OPJ3TPlJGHA.2088@xxxxxxxxxxxxxxxxxxxxxxx
>>>> Hm, are you sure the timeout period you are passing to
>>>> WaitForSingleObject hasn't expired? Does it show
>>>> the same behavior on INFINITE timeout?
>>>>
>>>>
>>>> "Mauro de Gennaro" <mdegennaro@xxxxxxxxxxxxx> wrote in message
>>>> news:uQW%23lFlJGHA.3064@xxxxxxxxxxxxxxxxxxxxxxx
>>>>> WaitForSingleObject(SomeEvent) returns WAIT_TIMEOUT after pressing F5
>>>>> to exit from breakpoint in Nr.3.
>>>>>
>>>>> Mauro
>>>>>
>>>>>
>>>>> "Voidcoder" <voidcoder@xxxxxxxxx> ha scritto nel messaggio
>>>>> news:uxEQeqkJGHA.3144@xxxxxxxxxxxxxxxxxxxxxxx
>>>>>> Not very clear, though. Do you mean WaitForSingleObject(SomeEvent)
>>>>>> in Nr.2 returns WAIT_TIMEOUT when you stop at breakpoint in Nr.3?
>>>>>>
>>>>>>
>>>>>>
>>>
>>>
>>>
>>> "Valter Minute" <vminute@xxxxxxxxxxxxxxxxxxxxx> ha scritto nel messaggio
>>> news:Xns975C779EE9A42VALTERMINUTE@xxxxxxxxxxxxxxxx
>>>> "Mauro de Gennaro" <mdegennaro@xxxxxxxxxxxxx> wrote in
>>>> news:uQW#lFlJGHA.3064@xxxxxxxxxxxxxxxxxxxx:
>>>>
>>>>> WaitForSingleObject(SomeEvent) returns WAIT_TIMEOUT after pressing
>>>>> F5 to exit from breakpoint in Nr.3.
>>>>>
>>>>
>>>> This happens if step-by-step debugging of other threads took too
>>>> long.
>>>> You may use a #define to set the timeout interval as a preprocessor
>>>> constant and convert it to INFINITE (or a longer time) when _DEBUG is
>>>> defined or when you #define a specific preprocessor symbol that will
>>>> enable step-by-step debugging mode in your application.
>>>> Something like:
>>>>
>>>> #ifdef STEP_BY_STEP_DEBUG
>>>> #define THREAD_3_TIMEOUT 500
>>>> #else
>>>> #define THREAD_3_TIMEOUT INFINITE
>>>> #endif
>>>>
>>>> If you use timeouts in Wait* calls to handle unexpected locks of
>>>> other threads, changing it's behaviour to an infinite wait should not
>>>> change your application behaviour and will allow you to perform step-
>>>> by-step debugging on another thread.
>>>>
>>>> --
>>>> Valter Minute
>>>> (the reply address of this message is invalid)
>>>> (l'indirizzo di reply di questo messaggio non è valido)
>>>
>>>
>>
>>
>
>


.

Relevant Pages

  • Re: multithreaded debugging
    ... Besides having kernel "ON" helps to better debug interface. ... debugging a thread without interfere with the other was really powerful, but now with EVC4 it isn't ...
    (microsoft.public.windowsce.platbuilder)
  • [BUG] panic 2.6.20-rc3 in nf_conntrack
    ... When I shut down my ppp0 interface the kernel ... This kernel had the ipp2p patch from patch-o-matic-ng applied, ... # Firmware Drivers ... # ACPI Support ...
    (Linux-Kernel)
  • [PATCH 3/3] Add documentation about why the in-kernel api is the way it is.
    ... +The Linux Kernel Driver Interface ... +kernel interface, nor does it have a stable kernel interface. ...
    (Linux-Kernel)
  • Re: [PATCH 0/7] dlm: overview
    ... > aren't just unique within a single cluster (think clusters of clusters, ... How the configuration gets from the config file to kernel is a mystery to me ... By a message over a socket, ... Let's have no magical filesystems in the core interface please. ...
    (Linux-Kernel)
  • [RFC] New kernel-message logging API
    ... Backwards compatibility with printk(), syslog, etc. ... way the whole kernel can be converted to a new interface in one go. ... const char *format; ...
    (Linux-Kernel)