Pause Debugger in worker thread possible?

[Zytan]

I have code running in the debugger as I type. I press pause, and it
pauses on:

Application.Run(new myForm());

*I believe* a worker thread is in deadlock (it's in a lock, but calls
another function that tries to use the same lock). If the main thread
was deadlocked, I think the debugger would stop right on that spot.
So, I assume that it is a worker thread that is deadlocked.

Is there any way to stop the debugger into a specific thread?
Any help is greatly appreciated!!

Zytan

 

[Peter Duniho]

I have code running in the debugger as I type. I press pause, and it
pauses on:

Application.Run(new myForm());

That's because in that thread, that's the location within your own code
where the thread is executing. If you'd managed to break during the
processing of an event for that form, you'd see the location as something
else.

*I believe* a worker thread is in deadlock (it's in a lock, but calls
another function that tries to use the same lock). If the main thread
was deadlocked, I think the debugger would stop right on that spot.
So, I assume that it is a worker thread that is deadlocked.

A thread cannot deadlock itself. That is, if a single thread has a lock,
and then attempts to get the same lock, it will succeed on the second (and
any subsequent) attempt to get the lock.

Deadlock occurs when (for example) one thread has a lock, a second thread
has a *different* lock, and each thread attempts to get the lock that the
other thread has. In that case, neither thread can get the lock it wants,
because the other thread is holding it, and neither thread will release the
lock that the other thread wants, because each thread is waiting to get the
lock that *it* wants.

Is there any way to stop the debugger into a specific thread?
Any help is greatly appreciated!!

For many months I was dismayed that the "Debug/Threads..." menu item was
removed. I had no idea where it went! I mentioned it several times in
these newsgroups, but no one had an answer. Turns out, there's a toolbar
called "Debug Location" that allows you to select the thread you want to
debug.

You'll find a bunch of threads in there that aren't ones you explicitly
made, which makes it a little trickier to find the thread you're interested
in. But you can just click through the list of threads until you find the
thread you want (hopefully you can recognize it by the code where the thread
is stopped).

Pete

 

[Zytan]

That's because in that thread, that's the location within your own code

where the thread is executing. If you'd managed to break during the
processing of an event for that form, you'd see the location as something
else.

Yes, ok. I was expecting that the debugger would know the 100% cpu
activity was in another thread, and show this, but that's silly, since
how would it really know to judge such things.

A thread cannot deadlock itself. That is, if a single thread has a lock,
and then attempts to get the same lock, it will succeed on the second (and
any subsequent) attempt to get the lock.

Yes, I resolved that myself a little while later. The TRUE bug was an
infintie loop in a worker thread.

I understand fully way the same thread can enter the same lock twice.
'lock' is to prevent different threads, not the same thread. I was
surprised by this coming from using critical sections. I shouldn't
really call 'locks' critical sections, then, since they are
different. Locks are better.

For many months I was dismayed that the "Debug/Threads..." menu item was
removed. I had no idea where it went! I mentioned it several times in
these newsgroups, but no one had an answer. Turns out, there's a toolbar
called "Debug Location" that allows you to select the thread you want to
debug.

Aaaaah!! You're a godsend! Thanks!!!

Hm, wait, I don't have a 'Debug Location' toolbar. I am running C#
2005 Express, is that why?

You'll find a bunch of threads in there that aren't ones you explicitly
made, which makes it a little trickier to find the thread you're interested
in. But you can just click through the list of threads until you find the
thread you want (hopefully you can recognize it by the code where the thread
is stopped).

Sure, great, thanks a lot, Pete!

Zytan

 

[Peter Duniho]

[...]
I understand fully way the same thread can enter the same lock twice.
'lock' is to prevent different threads, not the same thread. I was
surprised by this coming from using critical sections. I shouldn't
really call 'locks' critical sections, then, since they are
different. Locks are better.

Critical sections aren't any different. The same thread can re-enter the
same critical section as often as it wants or needs to.

[...]
Hm, wait, I don't have a 'Debug Location' toolbar. I am running C#
2005 Express, is that why?

Could very well be. I think I've still got an Express version installed on
a computer around here somewhere. If I have a moment, I'll take a look and
see if I can find the same toolbar in it. But it wouldn't surprise me to
find that they removed this very useful, but somewhat-advanced, feature from
Express.

Pete

 

[Zytan]

Critical sections aren't any different. The same thread can re-enter the

same critical section as often as it wants or needs to.

It can? I had no idea.

Could very well be. I think I've still got an Express version installed on
a computer around here somewhere. If I have a moment, I'll take a look and
see if I can find the same toolbar in it. But it wouldn't surprise me to
find that they removed this very useful, but somewhat-advanced, feature from
Express.

http://msdn2.microsoft.com/en-us/library/w15yf86f.aspx
says that C# Express doesn't have it.

Zytan

 

[Peter Duniho]

http://msdn2.microsoft.com/en-us/library/w15yf86f.aspx
says that C# Express doesn't have it.

Okie doke. I won't bother to check then.

You *can* debug a thread in Express by explicitly putting a breakpoint in
that thread's code. I know that works, because I've done it before. But of
course you have to have some idea of where you expect the code to be when
you want to interrupt it, for that to work. And you won't be able to look
at other threads, at least not easily (if I recall, it's possible the call
stack information can still be shown from other threads if you look at the
source window where those other threads are being called).

Basically, I know that at least some minimal thread-related debugging can be
done in Express; while I haven't done it recently, I do remember doing it a
little before I got around to installing the retail version of VS2005. I do
recommend the full version though, if you anticipate doing any significant
amount of multi-thread programming. Frankly, I'm surprised at just how much
they DID leave in Express, but there are a number of significant features
missing still. It's certainly worth the price of admission for the paid
version.

Pete

 

[Zytan]

You *can* debug a thread in Express by explicitly putting a breakpoint in

that thread's code.

Yup, I've done that before, so that will work.

Hm, you just made me think of something, maybe i could have put a
conditional breakpoint. I'll have to try that sometimes.

My real problem was that a worker thread was in an infinite loop, and
there's so many loops, i'd like to know which it was just by pressing
Pause, but I need the paid version of C# for that. I think that
feature alone is worth the money.

I do
recommend the full version though, if you anticipate doing any significant
amount of multi-thread programming. Frankly, I'm surprised at just how much
they DID leave in Express, but there are a number of significant features
missing still. It's certainly worth the price of admission for the paid
version.

I agree completely, thanks.

Zytan