Home > Archive > VC Language > November 2005 > systematic debugging of random freeze in debug mode
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
systematic debugging of random freeze in debug mode
|
|
| revyakin@yahoo.com 2005-11-21, 7:04 pm |
| My code contains a loop that has to perform calculations on data
streamed from a circular buffer. The calculation has to be performed
50,000+ times (about 30 ms per cycle) spitting out a number after each
cycle. The thing freezes in a poissonic manner (i.e. sometimes after 10
seconds of data aquizition, sometimes after 10 min of data aquizition,
etc). I do have the debugger attached. The program just stops
responding and I only can terminate it by "Debug->Stop debugging".
There are no indiciations in the Debug output window which would warn
me of the onset of the freeze. Since the freeze happens randomly, and I
don't see any feedback in the debugger, I am puzzled how I can
systematically debug this thing. Can anyone give a spepific advice on
where I could start?
| |
| revyakin@yahoo.com 2005-11-21, 7:04 pm |
| Sorry, I should've said I am using .NET and MFC.
| |
| Igor Tandetnik 2005-11-21, 7:04 pm |
| revyakin@yahoo.com wrote:
> My code contains a loop that has to perform calculations on data
> streamed from a circular buffer. The calculation has to be performed
> 50,000+ times (about 30 ms per cycle) spitting out a number after each
> cycle. The thing freezes in a poissonic manner (i.e. sometimes after
> 10 seconds of data aquizition, sometimes after 10 min of data
> aquizition, etc). I do have the debugger attached. The program just
> stops responding and I only can terminate it by "Debug->Stop
> debugging".
You can also do Debug | Break All and see what the code was doing at
the time.
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925
| |
| Mark Randall 2005-11-21, 7:04 pm |
| Call stack is going to be the best thing for you here IMO.
--
- Mark Randall
http://zetech.swehli.com
"Those people that think they know everything are a great annoyance to those
of us who do"
Isaac Asimov
<revyakin@yahoo.com> wrote in message
news:1132604876.491361.32310@g49g2000cwa.googlegroups.com...
> My code contains a loop that has to perform calculations on data
> streamed from a circular buffer. The calculation has to be performed
> 50,000+ times (about 30 ms per cycle) spitting out a number after each
> cycle. The thing freezes in a poissonic manner (i.e. sometimes after 10
> seconds of data aquizition, sometimes after 10 min of data aquizition,
> etc). I do have the debugger attached. The program just stops
> responding and I only can terminate it by "Debug->Stop debugging".
> There are no indiciations in the Debug output window which would warn
> me of the onset of the freeze. Since the freeze happens randomly, and I
> don't see any feedback in the debugger, I am puzzled how I can
> systematically debug this thing. Can anyone give a spepific advice on
> where I could start?
>
| |
| revyakin@yahoo.com 2005-11-21, 9:58 pm |
| Thanks a lot, Igor and Mark. I found a library file that was causing
this behavior using the call stack.
| |
| revyakin@yahoo.com 2005-11-21, 9:58 pm |
| even though I found what causes the trouble, Interestingly, I found
that both the stack call and the break call don't always point to the
actual process/dll causing the problem. I wonder what it means.
| |
| Igor Tandetnik 2005-11-21, 9:58 pm |
| <revyakin@yahoo.com> wrote in message
news:1132624140.364337.219740@g47g2000cwa.googlegroups.com...
> even though I found what causes the trouble, Interestingly, I found
> that both the stack call and the break call don't always point to the
> actual process/dll causing the problem. I wonder what it means.
There are probably several threads. Your code is on one of them, some
unrelated system code runs on the others. Open Threads window, find your
primary thread, switch to it and you'll get correct call stack.
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925
| |
| Ivan Brugiolo [MSFT] 2005-11-22, 4:01 am |
| On top of what other have suggested, the best way to debug
these configuration, is in my opinion, the non-invasive debugging
offered by the system debuggers cdb/ntsd/windbg.
You can attach non invasively a debugger to a hung process,
even if it's being alreadu debugged by devenv.exe.
c:\debuggers> cdb -pv -p <pid>
the, from the debuggers prompt, you can inspect the stack of all the
threads,
with `~*kb`, and, the running time as well, with `!runaway`.
If you post the output of the two previous commands on the forum,
with good symbols, most likely people would be able to help.
--
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
<revyakin@yahoo.com> wrote in message
news:1132604876.491361.32310@g49g2000cwa.googlegroups.com...
> My code contains a loop that has to perform calculations on data
> streamed from a circular buffer. The calculation has to be performed
> 50,000+ times (about 30 ms per cycle) spitting out a number after each
> cycle. The thing freezes in a poissonic manner (i.e. sometimes after 10
> seconds of data aquizition, sometimes after 10 min of data aquizition,
> etc). I do have the debugger attached. The program just stops
> responding and I only can terminate it by "Debug->Stop debugging".
> There are no indiciations in the Debug output window which would warn
> me of the onset of the freeze. Since the freeze happens randomly, and I
> don't see any feedback in the debugger, I am puzzled how I can
> systematically debug this thing. Can anyone give a spepific advice on
> where I could start?
>
|
|
|
|
|