visual studio locking up when debugging cross thread code

[Stephan Steiner]

Hi

I'm not sure this is the proper place but I couldn't find a dedicated group
for visual studio so here goes:

I used to write responsive GUIs by creating threads to process long running
operations, give feedback via event handler which ends up in the GUI
domain.. e.g like this.

object sharedState;
OperationHandler handler = new OperationHandler();
handler.Feedback += new FeedbackHandler(handler_feedback);
new Thread(new ThreadStart(handler.run)).Start();

public handlerFeedback(object feedbackState)
{
this.sharedState = feedbackState;
this.Invoke(new EventHandler(myEventHandler));
}

public void myEventHandler(object state, EventArgs e)
{
// do some processing in the GUI thread
}

where handler.run looks something like

void run()
{
while(running)
{
// do something
if (Feedback != null)
Feedback(myObject);
}
}

So far so good.. I've never had much of a problem debugging such code, but
there are more elegant ways of handling things.

So I switched to using the ThreadPool instead of creating my own threads. So
now instead of using

new Thread(new ThreadStart(handler.run)).Start();

to start the work, I use

ThreadPool.QueueUserWorkItem(handler.run, null);

The next step was swapping out the EventHandler and using an anonymous
delegate:

So

public handlerFeedback(object feedbackState)
{
this.sharedState = feedbackState;
this.Invoke(new EventHandler(myEventHandler));
}

becomes

public handlerFeedback(object feedbackState)
{
this.BeginInvoke((MethodInvoker)delegate()
{
// do some processing in the GUI thread
});
this.Invoke(new EventHandler(myEventHandler));
}

And tha's where I started getting problems. As long as I run the code
without any breakpoints, there's no problem, But suppose I set a breakpoint
within the anonymous method inside handlerFeedback.. then the method is hit,
I press F10 and Visual Studio just sits there doing nothing. After a while I
get the popup in the taskbar telling me VS is busy and if this happens often
to contact Microsoft. The thing is.. it happens way too often, and every
second or third time, pressing F10 will never return.. the app is still
accessible and interestingly enough, Visual Studio also still reacts, but
debugging just doesn't continue.

On top of making those changes, if I have the contents of handler.run in the
GUI class and inside and do something like:

void run()
{
while(running)
{
// do something
this.BeginInvoke((MethodInvoker)delegate()
{
// processing in the gui thread
});
}
}

I have the same issue.

Also, I've been using the

void someAsynchronousMethod(object state)
{
MyDelegate del = new MyDelegate(handler.run);
IAsyncResult ar = delegate.BeginInvoke(callback, state);
}

template quite a bit recently, then send back the result via an event to the
GUI class, and join the GUI thread via the

this.BeginInvoke((MethodInvoker)delegate()
{
// processing in the gui thread
});

logic - and that alone doesn't cause any problem so I think it's the
combination of the ThreadPool along with the use of anymous methods to join
the GUI thread that causes these locks.


Now I'm wondering.. am I doing something fundamentally wrong or does Visual
Studio just have major debugging issues in such a scenario and I should
either go back to doing things the more cumbersome way if I want to debug my
code?

Regards
Stephan

 

[Nicholas Paldino [.NET/C# MVP]]

Stephan,

This is expected behavior when you break in the debugger. ALL threads
stop processing when you hit a breakpoint, not just the one that is
processing the code you have set the breakpoint on.

 

[Stephan Steiner]

Hmm.. do we have a misunderstanding on our hands? If I understood your
message correctly, you are refering to the threads in my app - whereas
I am refering to visual studio (another process altogether). I realize
that a breakpoint breaks all threads, but if you step through the code
thereafter, all threads become active again (which can lead to funny
"line hopping" in the IDE when you have multiple threads executing the
same method e.g. for a multiuser system). And I'm not complaining
about my own GUI locking up.. Visual Studio locks up and that's
another process altogether and the warning that pops up in the taskbar
even hints that this may be a Visual Studio problem - it says it
shouldn't happen.

I never had any trouble debugging any software using multiple threads
(be it a software without any GUI and just multiple processing threads
or a GUI with background processing threads) - regardless of where I
place a breakpoint, it breaks as expected, and I can step through the
code no problem. I can even debug cross thread calls (e.g place a
breakpoint in the event handler getting feedback from a processing
thread, and another one in the EventHandler executing in the GUI
thread). It's really only when I use control.BeginInvoke together with
anonymous delegates that this problem happens. If I swap out the
anonymous delegate like this:


void run()
{
while(running)
{
// do something
this.BeginInvoke((MethodInvoker)delegate()
{
// processing in the gui thread
});
}
}

with the following

void run()
{
while(running)
{
// do something
this.BeginInvoke(new EventHandler(myEventHandler));
}
}

It works as expected so taht, along with the Visual Studio popup hint
that tells me to tell Microsoft if it keeps happening make me think
this is a Visual Studio issue. If not, do you have any explanation why
from the two examples above, the first locks up Visual Studio,
(regardless of whether the breakpoint is on the line "//do something"
or on "// processing in the gui thread") and the second does not
(again regardless of the placement of breakpoints)? Plus there's the
inconsistent behavior... the first time the breakpoint is hit, Visual
Studio shows the "busy" popup.. and then once the breakpoint finally
hits, if I press F10 to continue, if I'm lucky it does continue, if
I'm not, nothing happens and my software enters running state again.
Then the next time the breakpoint is hit, there's no waiting where my
application has stopped responding (so I presume the breakpoint has
been hit and all threads have been suspended) but where Visual Studio
doesn't yet show the breakpoint as hit and won't let me step through
the code.

Regards
Stephan