Re: 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