Debugging a multi-threaded application

Hi,

The platform and tools involved here are CE 4.2 running on a CEPC and eVC++
4.00 for program development and debugging.

This is a result of further testing on the problem in my previous post. I
created a small project with two very simple threads. The main process
creates a second thread which simply loops through incrementing a counter
and sleep for 100 ms. The main thread is in a loop with a 100 ms. sleep.
If I put a break point in the main thread and begin stepping through the
loop, the second thread stops executing. I can see this because the counter
value no longer increments. If I resume the main thread for a few seconds
and then break it again I can see that the counter has been incremented.

I sincerely hope this is a problem that can be fixed if I apply all the
QFE's to my platform. If not, the platform is essentially useless to us.
We do real-time machine control and our applications depend heavily on
multi-thread processes. Debugging these applications will be next to
impossible if all threads stop when one reaches a break point. We have no
problem doing this type of thing with CE 3.00.

Suggestions are welcome!

Thanks,

Jim Frazer

anonymous
Tue Jul 27 06:19:17 CDT 2004


This is how any OS would behave while debugging,
you could get a really unexpected behaviour
otherwise.

I've never seen this as a limitation. If you describe
what you try to do maybe anyone can suggest other
ways to solve your problem.

Maybe you could use an application debugger (as
opposed to PB) and put it in two different processes.

Jim
Tue Jul 27 11:17:49 CDT 2004

I don't know how to make this any clearer. The platform is up and running
and we're now porting applications from CE 3.00 to CE 4.2. For this
process, I am using eVC++ 4.0 and the debugger that it supports. I am NOT
using the debugger in Platform Builder. The behavior I am seeing is NOT
what occurs with CE 3.0 and eVC++ 3.0 and its debugger. CE 3.00 and its
tools do the job as we need it. With the 3.0 package we can place a
breakpoint in any thread in a multi-threaded application, and when the
breakpoint is reached, the other threads continue to execute.

Our software does real-time control of machinery. Typically, one thread
might control operation of a small section of the machine and another thread
another section of the machine. A third thread might receive messages from
the HMI (Human/Machine Interface) process. Breaking our applications apart
into separate processes would require complicated interprocess
communications and synchronization.

My problem is that I cannot determine whether this behavior is because of a
platform problem or a change in CE 4.2 or a change in eVC++ 4.2, or, as
Microsoft might put it, "by design". I can't imagine that this is an
intentional change in moving from CE 3.0 to CE 4.2.

Jim


<anonymous@discussions.microsoft.com> wrote in message
news:4d4001c473cb$8e4db870$a301280a@phx.gbl...
>
> This is how any OS would behave while debugging,
> you could get a really unexpected behaviour
> otherwise.
>
> I've never seen this as a limitation. If you describe
> what you try to do maybe anyone can suggest other
> ways to solve your problem.
>
> Maybe you could use an application debugger (as
> opposed to PB) and put it in two different processes.
>
>

Maxim
Tue Jul 27 12:29:20 CDT 2004

Is it a hard task to port this particular app to Windows NT?

If no - then it is a good idea, NT has great debugging tools - WinDbg,
SoftICE etc.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com


"Jim Frazer" <jtfrazer@nospam.net> wrote in message
news:OcShVrzcEHA.3928@TK2MSFTNGP09.phx.gbl...
> Hi,
>
> The platform and tools involved here are CE 4.2 running on a CEPC and eVC++
> 4.00 for program development and debugging.
>
> This is a result of further testing on the problem in my previous post. I
> created a small project with two very simple threads. The main process
> creates a second thread which simply loops through incrementing a counter
> and sleep for 100 ms. The main thread is in a loop with a 100 ms. sleep.
> If I put a break point in the main thread and begin stepping through the
> loop, the second thread stops executing. I can see this because the counter
> value no longer increments. If I resume the main thread for a few seconds
> and then break it again I can see that the counter has been incremented.
>
> I sincerely hope this is a problem that can be fixed if I apply all the
> QFE's to my platform. If not, the platform is essentially useless to us.
> We do real-time machine control and our applications depend heavily on
> multi-thread processes. Debugging these applications will be next to
> impossible if all threads stop when one reaches a break point. We have no
> problem doing this type of thing with CE 3.00.
>
> Suggestions are welcome!
>
> Thanks,
>
> Jim Frazer
>
>
>

sergeir
Wed Jul 28 07:15:31 CDT 2004

Hi Jim,

>-----Original Message-----
[skip]

>process, I am using eVC++ 4.0 and the debugger that it
supports. I am NOT using the debugger in Platform
Builder. The behavior I am seeing is NOT
>what occurs with CE 3.0 and eVC++ 3.0 and its debugger.
CE 3.00 and its
>tools do the job as we need it. With the 3.0 package we
can place a
>breakpoint in any thread in a multi-threaded application,
and when the
>breakpoint is reached, the other threads continue to
execute.

Correct. As far as I know :

a) that was by design in CE 3.0 and its eVC debugger.

b) That behavior was changed in CE 4.x to bring it to NT-
like debugging, when hitting a break point in any thread
will all do its best to stop executing all threads in your
being debugged process. You can then choose to set focus
on the thread desired or suspend them and execute just one
etc.

>Microsoft might put it, "by design". I can't imagine
that this is an
>intentional change in moving from CE 3.0 to CE 4.2.

It might be so.

>Jim

Sincerely
Sergei

Jim
Wed Jul 28 07:58:11 CDT 2004

sergeir,

> b) That behavior was changed in CE 4.x to bring it to NT-
> like debugging, when hitting a break point in any thread
> will all do its best to stop executing all threads in your
> being debugged process. You can then choose to set focus
> on the thread desired or suspend them and execute just one
> etc.

In eVC++ 4.0, setting the focus on the desired thread doesn't function, at
least on my installation, nor can I suspend or execute them. The window
that shows up when "Debug/Threads" is selected shows that the threads are
suspended, but the suspend status column shows 0 instead of 1 and the
"resume" button is greyed out. Attempting to set focus on a thread appears
to display memory from a random address with the contents all "????". This
function did work in eVC++ 3.00.

When one is doing real-time software that controls machinery, having a break
point in one thread stop all the others in the process can have catastrophic
results.

Jim



"sergeir" <anonymous@discussions.microsoft.com> wrote in message
news:59c501c4749c$9370cd20$a601280a@phx.gbl...
> Hi Jim,
>
> >-----Original Message-----
> [skip]
>
> >process, I am using eVC++ 4.0 and the debugger that it
> supports. I am NOT using the debugger in Platform
> Builder. The behavior I am seeing is NOT
> >what occurs with CE 3.0 and eVC++ 3.0 and its debugger.
> CE 3.00 and its
> >tools do the job as we need it. With the 3.0 package we
> can place a
> >breakpoint in any thread in a multi-threaded application,
> and when the
> >breakpoint is reached, the other threads continue to
> execute.
>
> Correct. As far as I know :
>
> a) that was by design in CE 3.0 and its eVC debugger.
>
> b) That behavior was changed in CE 4.x to bring it to NT-
> like debugging, when hitting a break point in any thread
> will all do its best to stop executing all threads in your
> being debugged process. You can then choose to set focus
> on the thread desired or suspend them and execute just one
> etc.
>
> >Microsoft might put it, "by design". I can't imagine
> that this is an
> >intentional change in moving from CE 3.0 to CE 4.2.
>
> It might be so.
>
> >Jim
>
> Sincerely
> Sergei
>

sergeir
Thu Jul 29 01:44:03 CDT 2004

Hi Jim,

>In eVC++ 4.0, setting the focus on the desired thread
doesn't function, at
>least on my installation, nor can I suspend or execute
them. The window

there were a number of eVC QFEs on that, as I recall. That
might fix some problems with UI not refreshing status of
threads correctly. This does not mean that all UI bugs
were fixed in that part.

>When one is doing real-time software that controls
machinery, having a break
>point in one thread stop all the others in the process
can have catastrophic results.

This depends on your approach. Basically you had assumed
that hitting a break point in one thread will not stop all
the others and then have based your design on that
assumption. I wouldn't do that, especially in case of
controlling machinery, since that would be a risky
assumption. At least desktop OS from the same manufacturer
like NT doesn't do that; this should ring a bell at least.

In your case, maybe, when migrating to CE 4.x, it might be
better to split your existing application into application
process and driver-level parts which would run at kernel
level and thus will not be stopped, when an application
break point is hit in eVC debugger. This is my IMHO, me is
not an expert in machinery control, though used to work on
application debugger in the past.

>Jim

Sincerely
Sergei

Dean
Thu Jul 29 10:04:14 CDT 2004

Drivers don't run in kernel context in CE - they are in user context just
like applications. Drivers run in the context of the device.exe process,
which would have the same behavior as applications. I wasn't aware of the
entire process stopping when any thread hit a breakpoint, but if that's the
case, then I would assume that setting a breakpoint in one thread of one
driver would cause all other driver threads to stop as well.

--
Dean Ramsier - eMVP


"sergeir" <anonymous@discussions.microsoft.com> wrote in message
news:636701c47537$702d6210$a301280a@phx.gbl...
> Hi Jim,
>
> >In eVC++ 4.0, setting the focus on the desired thread
> doesn't function, at
> >least on my installation, nor can I suspend or execute
> them. The window
>
> there were a number of eVC QFEs on that, as I recall. That
> might fix some problems with UI not refreshing status of
> threads correctly. This does not mean that all UI bugs
> were fixed in that part.
>
> >When one is doing real-time software that controls
> machinery, having a break
> >point in one thread stop all the others in the process
> can have catastrophic results.
>
> This depends on your approach. Basically you had assumed
> that hitting a break point in one thread will not stop all
> the others and then have based your design on that
> assumption. I wouldn't do that, especially in case of
> controlling machinery, since that would be a risky
> assumption. At least desktop OS from the same manufacturer
> like NT doesn't do that; this should ring a bell at least.
>
> In your case, maybe, when migrating to CE 4.x, it might be
> better to split your existing application into application
> process and driver-level parts which would run at kernel
> level and thus will not be stopped, when an application
> break point is hit in eVC debugger. This is my IMHO, me is
> not an expert in machinery control, though used to work on
> application debugger in the past.
>
> >Jim
>
> Sincerely
> Sergei
>

sergeir
Fri Jul 30 01:15:00 CDT 2004


>-----Original Message-----
>Drivers don't run in kernel context in CE - they are in
user context just
>like applications. Drivers run in the context of the
device.exe process,
>which would have the same behavior as applications.

That's what I was trying to say. For example - our app
would read tensometric data from the gauge. So we would
have

a) mytensorreeader.dll which is a driver and it runs at
least 1 thread in device.exe process and creates a device
TZR1:
We do not use eVC debugger to debug it when we debug the
app below.

b) tenzrrapp.exe which runs as an application, written in
eVC and debugged with eVC application debugger. When you
hit a break point in any thread of tenzrrapp.exe then all
its threads are eventually stopped by eVC application
debugger, but the one in device.exe process still runs
which is responsible for the dvice TZR1:.

That's the idea. Your application may have different
structure. The design of driver portion of your app may
also be different.

Sincerely
Sergei

I wasn't aware of the
>entire process stopping when any thread hit a breakpoint,
but if that's the
>case, then I would assume that setting a breakpoint in
one thread of one
>driver would cause all other driver threads to stop as
well.
>
>--
>Dean Ramsier - eMVP
>
>
>"sergeir" <anonymous@discussions.microsoft.com> wrote in
message
>news:636701c47537$702d6210$a301280a@phx.gbl...
>> Hi Jim,
>>
>> >In eVC++ 4.0, setting the focus on the desired thread
>> doesn't function, at
>> >least on my installation, nor can I suspend or execute
>> them. The window
>>
>> there were a number of eVC QFEs on that, as I recall.
That
>> might fix some problems with UI not refreshing status of
>> threads correctly. This does not mean that all UI bugs
>> were fixed in that part.
>>
>> >When one is doing real-time software that controls
>> machinery, having a break
>> >point in one thread stop all the others in the process
>> can have catastrophic results.
>>
>> This depends on your approach. Basically you had assumed
>> that hitting a break point in one thread will not stop
all
>> the others and then have based your design on that
>> assumption. I wouldn't do that, especially in case of
>> controlling machinery, since that would be a risky
>> assumption. At least desktop OS from the same
manufacturer
>> like NT doesn't do that; this should ring a bell at
least.
>>
>> In your case, maybe, when migrating to CE 4.x, it might
be
>> better to split your existing application into
application
>> process and driver-level parts which would run at kernel
>> level and thus will not be stopped, when an application
>> break point is hit in eVC debugger. This is my IMHO, me
is
>> not an expert in machinery control, though used to work
on
>> application debugger in the past.
>>
>> >Jim
>>
>> Sincerely
>> Sergei
>>
>
>
>.
>