Re: problems while debugger is attached

In VS.Net, you simply attach the debugger to the hanging
process AFTER it went into dead-lock. Then you open the
threads window and see where all your threads are. It
should be easy to find the one that's locked and get a
callstack. Especially if you have source for the system
lib in question.

Carsten Orthbandt
Founder + Development Director
SEK SpieleEntwicklungsKombinat GmbH
http://www.sek-ost.de

Wenn ich Visionen habe, gehe ich zum Arzt. - Helmut Schmidt
  

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] 
> On Behalf Of Andras Balogh
> Sent: Monday, July 24, 2006 1:09 AM
> To: [email protected]
> Subject: Re: [GD-General] problems while debugger is attached
> 
> The function call in question is a call into a 3rd party 
> library (ECW). I  
> have the sources and the .pdb, so I can step inside, and see 
> what's going  
> on, but of course, when I do that, it works fine.
> 
> Hmm, this gave me an idea: When I'm running the program without  
> breakpoints, I can still stop the execution of the process at 
> any time.  
> Now, Is there any way I could tell what the current 
> instrucion pointer is,  
> for each of my threads? That way, I could at least see, where 
> exactly the  
> execution is stalled.
> 
> Thanks,
> 
> 
> Andras
> 
> 
> On Sun, 23 Jul 2006 14:18:10 -0600, Chris Chapman 
> <[email protected]>  
> wrote:
> 
> > I've had this many times when coding in a multi-threaded 
> environment.
> > What will be happening is the attachment of the debugger is 
> enough to
> > skew the timings of the function calls so that a race condition is
> > exposed.
> >
> > When you say 'blocks on a function call and never returns', what
> > function call are you talking about? A system call or one 
> of your own
> > functions? If its one of your own functions thats blocking, 
> its a bit
> > easier to debug, because you can introduce logging around 
> it. A system
> > call is a harder to diagnose - usually the sub-system the 
> system call
> > is dealing with has some internal blocking, but its harder to figure
> > out where the race condition is coming from.
> >
> > Before I started using test driven development for these things, I
> > could spend ages beating my head against weird behaviour like that.
> > The most effective solution I found for debugging strange race
> > conditions was to introduce sleeps of random and 
> significant duration
> > around the system, to exacerbate any problems which don't show up
> > unless locks are held for a long while. Combine that with logging
> > around lock acquisition/releases so you can see what was going on
> > immediately prior to the deadlock, without having to use 
> breakpoints.
> > Breakpoints don't help at all in these cases, because they screw up
> > the timing, and the nature of debuggers is often to suspend other
> > threads entirely when single-stepping through a thread - 
> often making
> > the problem disappear entirely.
> >
> > ChrisC
> >
> > On 23/07/06, Andras Balogh <[email protected]> wrote:
> >> I have a strange bug, where if I'm running the program without the
> >> debugger attached (CTRL-F5 in VS), the program would run 
> correctly both  
> >> in
> >> debug and release builds. But when I run the program with 
> F5, so the
> >> debugger is attached, then it blocks on a function call and never  
> >> returns.
> >> If I put a breakpoint before this call, and step through it, then
> >> everything seems to work fine, and the function returns as 
> expected..
> >>
> >> Could this be a deadlocking problem? Any ideas why 
> attaching a debugger
> >> makes any difference? And hints on how to debug this?
> >>
> >> Thanks,
> >>
> >>
> >>
> >> Andras
> >>
> >> 
> --------------------------------------------------------------
> -----------
> >> Take Surveys. Earn Cash. Influence the Future of IT
> >> Join SourceForge.net's Techsay panel and you'll get the 
> chance to share  
> >> your
> >> opinions on IT & business topics through brief surveys -- 
> and earn cash
> >> 
> http://www.techsay.com/default.php?page=join.php&p=sourceforge
&CID=DEVDEV
> >> _______________________________________________
> >> Gamedevlists-general mailing list
> >> [email protected]
> >> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> >> Archives:
> >> http://sourceforge.net/mailarchive/forum.php?forum_id=557
> >>
> >
> > 
> --------------------------------------------------------------
> -----------
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the 
> chance to share  
> > your
> > opinions on IT & business topics through brief surveys -- 
> and earn cash
> > 
> http://www.techsay.com/default.php?page=join.php&p=sourceforge
&CID=DEVDEV
> > _______________________________________________
> > Gamedevlists-general mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> > Archives:
> > http://sourceforge.net/mailarchive/forum.php?forum_id=557
> 
> --------------------------------------------------------------
> -----------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the 
> chance to share your
> opinions on IT & business topics through brief surveys -- and 
> earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge
&CID=DEVDEV
> _______________________________________________
> Gamedevlists-general mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=557
> 

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Gamedevlists-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=557