Break debugger into worker thread?

[Zytan]

Can I break the debugger into a worker thread? Right now, my app is
freezing, and when I press pause, it stops on:

Application.Run(new MyForm());

I don't know what that means. I know the application starts there.
But why would the debugger stop on it? Why doesn't it stop where the
code is being run? I think there's a worker thread that is messed up.

Zytan

 

[Guest]

Hi Zytan,
the debugger will break there since the main UI thread will be sitting
waiting for Windows messages to process in the message loop.

Are you updating your controls using a different thread than the main UI
thread, using .Net1.1? If so this could explain your freezing.

Mark.

 

[Peter Duniho]

Can I break the debugger into a worker thread? Right now, my app is
freezing, and when I press pause, it stops on:

Application.Run(new MyForm());

I don't know what that means. I know the application starts there.
But why would the debugger stop on it? Why doesn't it stop where the
code is being run? I think there's a worker thread that is messed up.

I already answered most of this question, in reply to a different thread you
started.

The debugger didn't "stop on it"...it should be shown in green, which means
that it's simply part of the current call stack in one of your threads (in
this case, the main thread). And of course, it should be no surprise that
that line of code is part of the current call stack in one of your threads,
right?

When you break in the debugger, *all* threads are stopped. The debugger
shows you your main thread, but as I explained in the other post, you have
access to any thread you like. You just have to tell the debugger which one
you want to look at.

Pete

 

[Christof Nordiek]

Hi Zytan,

in addition to what Mark and Peter said: Open the threads window. There you
con switch between all threads. You can help to recognice your thread by
setting the Name property of the thread in code. This name will be shown in
the list.

Christof

 

[Zytan]

Are you updating your controls using a different thread than the main UI

thread, using .Net1.1? If so this could explain your freezing.

It was an infinite loop, haha!

Zytan

 

[Zytan]

I already answered most of this question, in reply to a different thread you

started.

Sorry for that. Google groups was not working, and I didn't think my
posts were being made. Then I seen new posts appearing, without mine,
so I posted again.

The debugger didn't "stop on it"...it should be shown in green, which means
that it's simply part of the current call stack in one of your threads (in
this case, the main thread). And of course, it should be no surprise that
that line of code is part of the current call stack in one of your threads,
right?

Yes, it shows in green. I've replicated my infinite loop just to test
this out. So, this main thread is just not doing anything (other than
handling UI info in the message loop that we cannot see), which is why
it shows on Application.Run, which is the lowest part of the call
stack for this main UI thread. Did I get it right?

When you break in the debugger, *all* threads are stopped.

Oh, I was under the impression that the others continued. How about
socket threads that are made from using Sockets? They must stop as
well, right?

The debugger
shows you your main thread, but as I explained in the other post, you have
access to any thread you like. You just have to tell the debugger which one
you want to look at.

Unfortunately, I cannot find out how to do this in C# 2005 Express...
but thanks for your help!

Zytan

 

[Zytan]

in addition to what Mark and Peter said: Open the threads window. There you

con switch between all threads. You can help to recognice your thread by
setting the Name property of the thread in code. This name will be shown in
the list.

http://msdn2.microsoft.com/en-us/library/w15yf86f(VS.80).aspx
C# - Express Edition - No

Damn! It's not included in Express......

Zytan

 

[Christof Nordiek]

Express edition doesn't have threads window? That's very bad, if you have to
debug multethreaded applications in C# Express edition. :-(

Then I can't see any way to switch the thread in the debugger. The only way
I can think of is putting a breakpoint somewhere where the worker thread (or
wich ever you want to debug), will come by.
Just an idea ;-)

Christof

 

[Peter Duniho]

Sorry for that. Google groups was not working, and I didn't think my
posts were being made. Then I seen new posts appearing, without mine,
so I posted again.

As a point of information:

As is the case with all newsgroups, this newsgroup is accessed via NNTP
servers (even using Google Groups, the back-end is NNTP), and NNTP servers
do not generally display submitted posts immediately. Depending on the
server and the current load, a post could take minutes or even hours to show
up. With direct access to the NNTP server, hours is pretty rare, but Google
doesn't provide you with direct access to the NNTP server and I've noticed
it can take longer for posts to show up there.

Patience is a virtue.

Yes, it shows in green. I've replicated my infinite loop just to test
this out. So, this main thread is just not doing anything (other than
handling UI info in the message loop that we cannot see), which is why
it shows on Application.Run, which is the lowest part of the call
stack for this main UI thread. Did I get it right?

Depending on the code you've written for the main form, it's possible to
manage to break just at the right moment when your code for that form is
executing. In that case, the debugger would show your execution location in
yellow at the actual point of execution.

Of course, if you set a break point or call the "debug break" method
explicitly in the main form's code, then you are assured of breaking in that
main thread, in the code you've written.

Also, it's not really so much that the call to Application.Run() is the
"lowest part of the call stack" for that thread. It just happens to be the
lowest part that is in *your* code. The thread is actually executing deeper
down than that, which is in fact why the location is green rather than
yellow. If you had the source and a PDB for the code that was executing (in
the system code in this case), the debugger would have shown you that code
(and it will when the code happens to be your own, since in that case you
*do* have the source and a PDB for it).

Oh, I was under the impression that the others continued. How about
socket threads that are made from using Sockets? They must stop as
well, right?

Yes, every thread in the process stops. A corallary to this is that when
you use a "step" command in the debugger, every thread gets to run as well
*but* you only get to control line-by-line the thread you're looking at.
This can produce some challenging "debugging-only" scenarios in buggy
multi-threaded code.

Pete

 

[Zytan]

As is the case with all newsgroups, this newsgroup is accessed via NNTP

servers (even using Google Groups, the back-end is NNTP), and NNTP servers
do not generally display submitted posts immediately. Depending on the
server and the current load, a post could take minutes or even hours to show
up. With direct access to the NNTP server, hours is pretty rare, but Google
doesn't provide you with direct access to the NNTP server and I've noticed
it can take longer for posts to show up there.

Ok, thanks. I thought I had waited a day, but it may have been the
same day only hours later. I'm doing so many things at once, I
forget. Also, I thought google had not accepted a post of mine
before. But, now that I think of it, it was just delayed, too, about
a day.

Depending on the code you've written for the main form, it's possible to
manage to break just at the right moment when your code for that form is
executing. In that case, the debugger would show your execution location in
yellow at the actual point of execution.

Yes, it shows as yellow, I just tried it. I never noticed the color
difference before. So, green means code that is NOT currently being
run. Ok.

Also, it's not really so much that the call to Application.Run() is the
"lowest part of the call stack" for that thread. It just happens to be the
lowest part that is in *your* code. The thread is actually executing deeper
down than that, which is in fact why the location is green rather than
yellow. If you had the source and a PDB for the code that was executing (in
the system code in this case), the debugger would have shown you that code
(and it will when the code happens to be your own, since in that case you
*do* have the source and a PDB for it).

Yes, it doesn't bother me with the inner details of the .NET code, it
shows me only my own stuff.

Yes, every thread in the process stops. A corallary to this is that when
you use a "step" command in the debugger, every thread gets to run as well
*but* you only get to control line-by-line the thread you're looking at.
This can produce some challenging "debugging-only" scenarios in buggy
multi-threaded code.

I can imagine, wow. Thanks for the information, this helps a lot!

Zytan

 

[Zytan]

At least next time I'll know to check for infinite loops..

Zytan

 

[Peter Duniho]

[...]

Depending on the code you've written for the main form, it's possible to
manage to break just at the right moment when your code for that form is
executing. In that case, the debugger would show your execution location
in
yellow at the actual point of execution.

Yes, it shows as yellow, I just tried it. I never noticed the color
difference before. So, green means code that is NOT currently being
run. Ok.

Define "currently being run".

When you break in the debugger, *no* code is "currently being run", since
all of the code is stopped. On the other hand, yes...when you see yellow,
that's where the actual instruction pointer is. Green shows you locations
that are in your call stack and so the instruction pointer will eventually
be returned to that location, but is currently not there.

I hope that makes sense, and is what you meant.

Pete

 

[Zytan]

Define "currently being run".

When you break in the debugger, *no* code is "currently being run", since
all of the code is stopped. On the other hand, yes...when you see yellow,
that's where the actual instruction pointer is. Green shows you locations
that are in your call stack and so the instruction pointer will eventually
be returned to that location, but is currently not there.

I hope that makes sense, and is what you meant.

This all makes perfect sense, Pete, thanks!

Zytan