Author: Heiner Marxen
Date: 11:50:09 07/12/01
Go up one level in this thread
On July 12, 2001 at 13:38:28, Gian-Carlo Pascutto wrote:
>On July 12, 2001 at 11:05:03, Robert Hyatt wrote:
>
>>Have you tried it by compiling with -g, then running under gdb and when it
>>crashes, typing "where"?
>
>#0 0x75 in ?? ()
>(gdb) where
>#0 0x75 in ?? ()
>Cannot access memory at address 0x0
>(gdb)
>
>The weird thing is that MSVC reports the exact same bogus location
>(0x75).
>
>>That should show you what called what, unless you
>>are blowing out memory which might wipe out the ability to trace back thru
>>the stack frames to see how the calls were done...
>
>I suspect very much this is the case, but what to do about it?
>
>--
>GCP
Yes, I share your suspicions: most probably the program overruns some
stack array, and by that destroys the stack frame linkage. Unfortunately,
the program crashes not before the garbage on the stack has been used
to perform a procedure return. During procedure return the code address
to which to jump back to is popped from the stack, and this is also destroyed.
So you wind up at some completely bogus code address, with no valid stack
frame linkage. That defeats post mortem debugging.
The main question to answer is: which function's stack gets destroyed?
There are some methods to apply in such a case:
(1) Examine the left over stack contents yourself, i.e. read it in 4-byte
words until you
(a) either find something looking like a valid stack frame containing
a return address. That might help to guess the function call.
or (b) recognise the specific offending contents on the stack.
If e.g. you recognize part of a move list there, or some ASCII string,
you may be able to spot the code that placed it there.
(2) Start the program under the debugger in the first place, and let it tell
about each and every function call and return. When it crashes, look at
the last few lines of that output.
I'm not sure which debugger does offer such a function, but it is _so_
useful, it should be there.
(3) Use your own verbose mode to find the function within which the desaster
happenes. E.g. produce a line of debug output for each MakeMove() and
each UndoMove(). Let the program attach a running count to these lines.
Determine the last running number befor the crash.
Add code, that starts to produce "I am here" messages when that number
is reached. A useful macro could look like:
#define HERE() if(neardesaster) {\
fprintf(debugfp, "HERE: %s %d\n", __FILE__, __LINE__);\
fflush(debugfp);\
}
Eventually you have narrowed down the region of the offending code to a small
enough part of the source, that you can start very careful proof reading.
(4) Check all automatic (stack) arrays, whether the code for sure does not
access behind or before it.
This could be done even without any actual crash.
Hope this helps somewhat.
Regards,
Heiner
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.