Re: [GD-General] problems while debugger is attached
Brought to you by:
vexxed72
Menu
▾
▴
Re: [GD-General] problems while debugger is attached
|
From: Carsten O. <car...@se...> - 2006-07-24 06:27:40
|
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 =20 > -----Original Message----- > From: gam...@li...=20 > [mailto:gam...@li...]=20 > On Behalf Of Andras Balogh > Sent: Monday, July 24, 2006 1:09 AM > To: gam...@li... > Subject: Re: [GD-General] problems while debugger is attached >=20 > The function call in question is a call into a 3rd party=20 > library (ECW). I =20 > have the sources and the .pdb, so I can step inside, and see=20 > what's going =20 > on, but of course, when I do that, it works fine. >=20 > Hmm, this gave me an idea: When I'm running the program without =20 > breakpoints, I can still stop the execution of the process at=20 > any time. =20 > Now, Is there any way I could tell what the current=20 > instrucion pointer is, =20 > for each of my threads? That way, I could at least see, where=20 > exactly the =20 > execution is stalled. >=20 > Thanks, >=20 >=20 > Andras >=20 >=20 > On Sun, 23 Jul 2006 14:18:10 -0600, Chris Chapman=20 > <can...@gm...> =20 > wrote: >=20 > > I've had this many times when coding in a multi-threaded=20 > environment. > > What will be happening is the attachment of the debugger is=20 > 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=20 > of your own > > functions? If its one of your own functions thats blocking,=20 > its a bit > > easier to debug, because you can introduce logging around=20 > it. A system > > call is a harder to diagnose - usually the sub-system the=20 > 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=20 > 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=20 > 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 -=20 > often making > > the problem disappear entirely. > > > > ChrisC > > > > On 23/07/06, Andras Balogh <and...@gm...> 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=20 > correctly both =20 > >> in > >> debug and release builds. But when I run the program with=20 > F5, so the > >> debugger is attached, then it blocks on a function call and never =20 > >> returns. > >> If I put a breakpoint before this call, and step through it, then > >> everything seems to work fine, and the function returns as=20 > expected.. > >> > >> Could this be a deadlocking problem? Any ideas why=20 > attaching a debugger > >> makes any difference? And hints on how to debug this? > >> > >> Thanks, > >> > >> > >> > >> Andras > >> > >>=20 > -------------------------------------------------------------- > ----------- > >> Take Surveys. Earn Cash. Influence the Future of IT > >> Join SourceForge.net's Techsay panel and you'll get the=20 > chance to share =20 > >> your > >> opinions on IT & business topics through brief surveys --=20 > and earn cash > >>=20 > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge &CID=3DDEVDEV > >> _______________________________________________ > >> Gamedevlists-general mailing list > >> Gam...@li... > >> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general > >> Archives: > >> http://sourceforge.net/mailarchive/forum.php?forum_id=3D557 > >> > > > >=20 > -------------------------------------------------------------- > ----------- > > Take Surveys. Earn Cash. Influence the Future of IT > > Join SourceForge.net's Techsay panel and you'll get the=20 > chance to share =20 > > your > > opinions on IT & business topics through brief surveys --=20 > and earn cash > >=20 > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge &CID=3DDEVDEV > > _______________________________________________ > > Gamedevlists-general mailing list > > Gam...@li... > > https://lists.sourceforge.net/lists/listinfo/gamedevlists-general > > Archives: > > http://sourceforge.net/mailarchive/forum.php?forum_id=3D557 >=20 > -------------------------------------------------------------- > ----------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the=20 > chance to share your > opinions on IT & business topics through brief surveys -- and=20 > earn cash > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge &CID=3DDEVDEV > _______________________________________________ > Gamedevlists-general mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-general > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=3D557 >=20 |
