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

[Andras B. <and...@gm...>]

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 goin=
g  =

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 i=
s,  =

for each of my threads? That way, I could at least see, where exactly th=
e  =

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 bo=
th  =

>> 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 debugg=
er
>> 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 sha=
re  =

>> your
>> opinions on IT & business topics through brief surveys -- and earn ca=
sh
>> http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CI=
D=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
>>
>
> ----------------------------------------------------------------------=
---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to shar=
e  =

> your
> opinions on IT & business topics through brief surveys -- and earn cas=
h
> 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