Re: [GD-General] problems while debugger is attached

[Chris C. <can...@gm...>]

Visual Studio does let you do this, although I'll stress again that
its behaviour when execution is supposedly frozen and single stepping
is not clear or obvious. Under the Debug menu there should be a
'Threads...' item (its a window in VS.NET), which should show you all
the currently running threads and the function in which their IP is
currently. Usually when you look at it you just see windows DLLs
though, as most often its a low level system call which yields the
thread. You can switch context to each thread and look at its call
stack to find some interesting results though.

On 24/07/06, Andras Balogh <and...@gm...> wrote:
> 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 <can...@gm...>
> 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 <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 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
> >> Gam...@li...
> >> 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
> > Gam...@li...
> > 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
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=557
>