From: kagel AT quasar DOT bloomberg DOT com Date: Wed, 18 Dec 1996 09:21:04 -0500 Message-Id: <9612181421.AA15686@quasar.bloomberg.com > To: Dik DOT Kettenis AT USERS DOT INFO DOT WAU DOT NL Cc: djgpp AT delorie DOT com In-Reply-To: (message from dik kettenis on Wed, 18 Dec 1996 11:29:54 +0100 (MET)) Subject: Re: A problem for gurus, I guess Reply-To: kagel AT dg1 DOT bloomberg DOT com Errors-To: postmaster AT ns1 Date: Wed, 18 Dec 1996 11:29:54 +0100 (MET) From: dik kettenis 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