Mail Archives: djgpp/1996/12/18/09:41:43
Errors-To: postmaster AT ns1
Date: Wed, 18 Dec 1996 11:29:54 +0100 (MET)
From: dik kettenis <Dik DOT Kettenis AT USERS DOT INFO DOT WAU DOT NL>
X-Envelope-To: djgpp AT delorie DOT com
Mime-Version: 1.0
Content-Transfer-Encoding: 7BIT
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=US-ASCII
Content-Length: 1163
Dear GPP-expert,
A program compiled with the newest version of GNU C for MSDOS returned to
MSDOS before the exit of the program. I started to debug this prgram with
GDB. At this time I have found a trouble spot, but I do not know what is
wrong. The following appears:
1. Running the program under GDB without any breaks: computer hangs
2. Stepping with s to the trouble spot: computer hangs
3. Stepping to the trouble spot (a call to a user defined function) with
s, continuing the execution with stepi executes the program to the
normal exit.
4. Running the program under GDB to a break at the assembler instruction
following the assembler call to the function:
the program returns from the call, so the break will be reached.
Two situations:
a: stepping further with s: program executes to the normal exit.
b: resuming execution by cont: machine hangs.
I hope this sounds familiar to at least one of the experts. Hopefully
someone can give me advise how to find the reason of my original
problem. I can post the code but the code is including some other
functions rather lengthy.
Please respond to my personal email address. Regards, Dik
This effect is indicative of a memory overwrite, probably but not necessarily
in the function you have identified (it might be in a previously called
routine). The cause of the different runtime behaviors is that the GDB loads
your program at a different location in memory than it would load normally so
the memory overwrite may affect different code or data. Also single stepping
actually moves an instruction to a temp area inserting a break after the next
statement or instruction. This action can also change behavior. Instruction
stepping would protect each instruction this way preventing the crash while
source level stepping only protects one out of a group of instructions
representing the corresponding "C" statement.
That is the explanation. The solution? Check the function in question and the
last one or two functions called immediately before it (though I suspect the
same function which is crashing) for writes to uninitialized local pointers or
to arrays beyond their boundaries. (This last is the most likely cause as it
looks like the call stack is being trashed. You could check this by having GDB
print the call stack periodically as you step through the function and see when
it is being trashed, if at all.)
Hope that this is enough.
--
Art S. Kagel, kagel AT quasar DOT bloomberg DOT com
A proverb is no proverb to you 'till life has illustrated it. -- John Keats
- Raw text -