By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,665 Members | 1,900 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,665 IT Pros & Developers. It's quick & easy.

Debugging threads in Visual Studio 2005

P: n/a
I have been using Visual Studio 2005 for some time now, and generally it
works fine. Recently I have been adding some threading logic to one of
my applications to permit the user interface to be updated while some
other process (CPU or I/O bound) is executing.

Before I added the threading the code worked fine and I could set
breakpoints anywhere and they were hit very quickly.

After adding the threading, the code executes very quickly, even
producing an exception, as long as there are not breakpoints in the
threaded code. As soon as I set a breakpoint in the threaded code, it
can take 30-45 seconds for my breakpoint to be hit! Even when I do hit
the breakpoint, and debug command (Continute, Step Over or Step Into)
seems to abort the thread!

Am I missing something in the configuration of the IDE?

-ken
Dec 21 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a
Hello Ken,

It could be everything, like race conditions, deadlock.
The problem seems to be in the code

KA> I have been using Visual Studio 2005 for some time now, and
KA> generally it works fine. Recently I have been adding some threading
KA> logic to one of my applications to permit the user interface to be
KA> updated while some other process (CPU or I/O bound) is executing.
KA>
KA> Before I added the threading the code worked fine and I could set
KA> breakpoints anywhere and they were hit very quickly.
KA>
KA> After adding the threading, the code executes very quickly, even
KA> producing an exception, as long as there are not breakpoints in the
KA> threaded code. As soon as I set a breakpoint in the threaded code,
KA> it can take 30-45 seconds for my breakpoint to be hit! Even when I
KA> do hit the breakpoint, and debug command (Continute, Step Over or
KA> Step Into) seems to abort the thread!
KA>
KA> Am I missing something in the configuration of the IDE?
KA>
KA> -ken
KA>
---
WBR,
Michael Nemtsev :: blog: http://spaces.msn.com/members/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsche
Dec 21 '05 #2

P: n/a
The actual exception I was attempting to track down was in my code, but
the behaviour of the debugger when setting a breakpoint in anything
other than the main thread is not.

I found the exception problem and fixed it, and now the code runs
properly, but if I set a breakpoint in the thread code, when it is to be
hit there is a large delay (10-60 seconds) before the debugger is
invokded. Once the breakpoint is hit, the only thing I do is press F11,
F10 or F5 and the thread seems to terminate. When I hit the breakpoint
the thread is active, and if I do not set a breakpoint, the code work,
so this is something in the IDE.

-ken

Michael Nemtsev wrote:
Hello Ken,

It could be everything, like race conditions, deadlock.
The problem seems to be in the code

KA> I have been using Visual Studio 2005 for some time now, and
KA> generally it works fine. Recently I have been adding some threading
KA> logic to one of my applications to permit the user interface to be
KA> updated while some other process (CPU or I/O bound) is executing.
KA> KA> Before I added the threading the code worked fine and I could set
KA> breakpoints anywhere and they were hit very quickly.
KA> KA> After adding the threading, the code executes very quickly, even
KA> producing an exception, as long as there are not breakpoints in the
KA> threaded code. As soon as I set a breakpoint in the threaded code,
KA> it can take 30-45 seconds for my breakpoint to be hit! Even when I
KA> do hit the breakpoint, and debug command (Continute, Step Over or
KA> Step Into) seems to abort the thread!
KA> KA> Am I missing something in the configuration of the IDE?
KA> KA> -ken
KA> ---
WBR,
Michael Nemtsev :: blog: http://spaces.msn.com/members/laflour

"At times one remains faithful to a cause only because its opponents do
not cease to be insipid." (c) Friedrich Nietzsche

Dec 21 '05 #3

P: n/a
Michael Nemtsev <ne*****@msn.com> wrote:
It could be everything, like race conditions, deadlock.
The problem seems to be in the code


None of that should give the symptoms shown IMO, and frankly if the
problem *is* in the code, wouldn't you expect to be able to at least
have a crack at it in the debugger? It sounds like it's either a
debugger bug, or something very odd going on.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Dec 21 '05 #4

P: n/a
I have the exact same problem :-(

the location where the debugger freezes and then aborts the thread is moving
around while the program grows. it happens exactly once after restarting the
debug session and it happens always on a newly spawned thread. It doesn't
matter whether i single-step or run up to the breakpoint, it fails at the
same breakpoint.

retrying the exact same sequence after the failure works perfectly.
thanks to the new 'edit and continue' feature i don't have to restart the
debugger that much.

i think its a bug in the ide, the debugger or both

reto


"Ken Allen" <ke******@sympatico.ca> wrote in message
news:%2***************@TK2MSFTNGP09.phx.gbl...
The actual exception I was attempting to track down was in my code, but
the behaviour of the debugger when setting a breakpoint in anything other
than the main thread is not.

I found the exception problem and fixed it, and now the code runs
properly, but if I set a breakpoint in the thread code, when it is to be
hit there is a large delay (10-60 seconds) before the debugger is
invokded. Once the breakpoint is hit, the only thing I do is press F11,
F10 or F5 and the thread seems to terminate. When I hit the breakpoint the
thread is active, and if I do not set a breakpoint, the code work, so this
is something in the IDE.

-ken

Michael Nemtsev wrote:
Hello Ken,

It could be everything, like race conditions, deadlock.
The problem seems to be in the code

KA> I have been using Visual Studio 2005 for some time now, and
KA> generally it works fine. Recently I have been adding some threading
KA> logic to one of my applications to permit the user interface to be
KA> updated while some other process (CPU or I/O bound) is executing.
KA> KA> Before I added the threading the code worked fine and I could set
KA> breakpoints anywhere and they were hit very quickly.
KA> KA> After adding the threading, the code executes very quickly, even
KA> producing an exception, as long as there are not breakpoints in the
KA> threaded code. As soon as I set a breakpoint in the threaded code,
KA> it can take 30-45 seconds for my breakpoint to be hit! Even when I
KA> do hit the breakpoint, and debug command (Continute, Step Over or
KA> Step Into) seems to abort the thread!
KA> KA> Am I missing something in the configuration of the IDE?
KA> KA> -ken
KA> ---
WBR,
Michael Nemtsev :: blog: http://spaces.msn.com/members/laflour

"At times one remains faithful to a cause only because its opponents do
not cease to be insipid." (c) Friedrich Nietzsche


Dec 21 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.