Debugging thread problem

[John Brown]

Hi there,

Has anyone had any problems debugging a thread in VS 2005. If I put a
breakpoint on a worker thread (the only one in the app) and then run the app
two things happen:

1) It takes an unusually long time for the breakpoint to kick in once
encountered
2) When it finally does break, I can't step through any code. As soon as I
try, the debugger just runs off somewhere and never returns control to me.

Any suggestions? Thanks..

 

[John Brown]

Update:

Unless there's some way to corrupt memory in C#/.NET (I'm relatively new to
it but very experienced in C/C++), this appears to be a VS bug though any
feedback would still be appreciated. That is, if I situate my breakpoint
earlier in the code I can debug no problem. If I then move the breakpoint
ahead one line at time, I eventually reach a point where the problem
suddenly surfaces. This occurs when I move the breakpoint to the first line
of a function outside the file where the thread actually starts. As soon as
I try to step into that function, the debugger takes about 20 seconds to do
so and when it finally does break, I can no longer step at all since the
debugger never returns. At one point I did notice a very brief message flash
on the bottom of the screen (in a small yellow window) to the effect that VS
was waiting for some internal operation to finish or something like that (it
flashed too quicly too digest it all). Anyway, this is a serious problem if
I can't debug my thread so any input would be welcome. Thanks.

 

[Willy Denoyette [MVP]]

| Hi there,
|
| Has anyone had any problems debugging a thread in VS 2005. If I put a
| breakpoint on a worker thread (the only one in the app) and then run the
app
| two things happen:
|
| 1) It takes an unusually long time for the breakpoint to kick in once
| encountered
| 2) When it finally does break, I can't step through any code. As soon as I
| try, the debugger just runs off somewhere and never returns control to me.
|
| Any suggestions? Thanks..
|
|

What kind of application is this? Windows forms or console like.
If Windows forms, do you pass the form object to the other thread?

Willy.

 

[John Brown]

What kind of application is this? Windows forms or console like.

If Windows forms, do you pass the form object to the other thread?

Well, the worker thread's main function (entry point) is a member of a
"Form" derivative and it passes a reference to the enclosing object (form)
to a function in another file and that's exactly where things start failing
(as soon as the latter function is called). However, note that all GUI
processing is being routed back to the main GUI thread via
"Control.Invoke()". In any case, is there a reason it should fail as soon
that function is called (perhaps you're alluding to some marshalling issue I
haven't considered - does the form's reference need to be marshalled to the
thread in some way). Thanks for your assistance (appreciated).

 

[Samuel R. Neff]

I've noticed this problem when stepping from code we have source for
to code we don't have source for (a 3rd party dll) when the other code
was compiled width debugging enabled. I most often run into this when
debugging unit tests and I step past the end of one test and control
returns to the test framework.

Does the problem occur always on a particular line of code? What
happens if instead of stepping into this line you step over it? Can
you set a breakpoint later in the program and it works ok (past the
offending line)?

Sam

 

[John Brown]

I've noticed this problem when stepping from code we have source for

to code we don't have source for (a 3rd party dll) when the other code
was compiled width debugging enabled. I most often run into this when
debugging unit tests and I step past the end of one test and control
returns to the test framework.

Does the problem occur always on a particular line of code? What
happens if instead of stepping into this line you step over it? Can
you set a breakpoint later in the program and it works ok (past the
offending line)?

I can step all over the function in file 1 anyway I like but as soon as I
call a function in file 2 the problem starts (I own all source). Willy may
be on to something however since I just discovered that the problem stops
when I pass "null" to the offending function in file 2 instead of the "Form"
reference I normally pass. I think there may be some marshalling issue here
perhaps (with the form's reference). The situation is quite simple however.
A form starts the worker thread going in its "OnLoad()" handler by invoking
"BackgroundWorker.RunWorkerAsync()" (standard 2.0 class). The worker thread
(another function in the form's class) then passes "this" to a function in
another file. That's when all the trouble starts. The debugger goes away for
a 20 second smoke (or whatever it's doing) and then it finally breaks at the
first line in the latter function. At this point however I can't step any
further without the debugger going into la la land permanently. Passing
"null" instead of "this" however eliminates the problem. I thought that
perhaps instead of passing "this", maybe I need to marshal the form's
pointer to the thread somehow but if so then it's news to me (I'm relatively
new to C# and .NET though very experienced in C/C++). Any thoughts?

 

[John Brown]

What kind of application is this? Windows forms or console like.

Well, the worker thread's main function (entry point) is a member of a
"Form" derivative and it passes a reference to the enclosing object (form)
to a function in another file and that's exactly where things start
failing (as soon as the latter function is called). However, note that all
GUI processing is being routed back to the main GUI thread via
"Control.Invoke()". In any case, is there a reason it should fail as soon
that function is called (perhaps you're alluding to some marshalling issue
I haven't considered - does the form's reference need to be marshalled to
the thread in some way). Thanks for your assistance (appreciated).

By sheer coincidence I came across the following link while pursuing another
matter related to this problem (what luck!). I'm still tinkering but the
"DebuggerDisplay" attribute seems to have solved the problem for the moment.
See the "System.Windows.Forms.Form and multithreading" section here:

http://blogs.msdn.com/greggm/archive/2005/11/18/494648.aspx

 

[Cor Ligthert [MVP]]

John,

Although in VB.Net do I have the same problem. I hope that this is one of
the fixes done in the next service pack, because this makes multithreading
not fine to use at the moment in my idea. My screen is completely blanked
out in those cases.

(The Microsoft development debugger team is AFAIK the same for C# and
VB.Net).

Cor

 

[Willy Denoyette [MVP]]

| >> What kind of application is this? Windows forms or console like.
| >> If Windows forms, do you pass the form object to the other thread?
| >
| > Well, the worker thread's main function (entry point) is a member of a
| > "Form" derivative and it passes a reference to the enclosing object
(form)
| > to a function in another file and that's exactly where things start
| > failing (as soon as the latter function is called). However, note that
all
| > GUI processing is being routed back to the main GUI thread via
| > "Control.Invoke()". In any case, is there a reason it should fail as
soon
| > that function is called (perhaps you're alluding to some marshalling
issue
| > I haven't considered - does the form's reference need to be marshalled
to
| > the thread in some way). Thanks for your assistance (appreciated).
|
| By sheer coincidence I came across the following link while pursuing
another
| matter related to this problem (what luck!). I'm still tinkering but the
| "DebuggerDisplay" attribute seems to have solved the problem for the
moment.
| See the "System.Windows.Forms.Form and multithreading" section here:
|
| http://blogs.msdn.com/greggm/archive/2005/11/18/494648.aspx
|
|

Righht John, that's exactly what you are after, I hope one of the
work-arounds will help you out.

Willy.

 

[John Brown]

Righht John, that's exactly what you are after, I hope one of the

work-arounds will help you out.

So far so good. Thanks for your help. Hopefully MSFT will get around to
repairing this situation as I'm sure many others have endured the same
frustration.