Mail Archives: djgpp-workers/1999/06/20/03:58:26
Erik, please cc: your messages to djgpp-workers, if you don't already,
since I think it's a good idea to let other people see this thread.
On Fri, 18 Jun 1999, Erik Berglund wrote:
> Call frame traceback EIPs:
> 0x00175777 _free+119
> 0x00173755 _obstack_free+49
> 0x000dbcb6 _reload+3730
This looks like some code is overwriting a buffer allocated by
malloc, or freeing some buffer that is already freed.
One way of investigating this would be as follows:
- disassemble cc1.exe near the point of the crash;
- look at the machine code and at the source for malloc (from
djlsrNNN.zip), and find out what address gets corrupted and causes
the SIGSEGV;
- run cc1.exe under a debugger, with exactly the same command line
that GCC is passing it (use "gcc -v" to see the command line), and
put a data breakpoint at the address that is causing SIGSEGV;
- when the data breakpoint is hit, look at the code that accesses
the offending address, to find out the villain which corrupts it.
You might need the latest version of GDB or RHIDE to get reliable
support for data breakpoints. I can send you the binary of GDB 4.18 I
am using, if you want.
Note that the DJGPP debug support has problems on Windows 3.X (see
section 12.10 of the FAQ for details), but hardware-assisted data
breakpoints which use debug registers should work nontheless. For
code breakpoints, be sure to use "hbreak" command.
> I also couldn't resist patching
> cc1.exe-2.95 in the same manner as I did before (using Unixy sbrk),
> and behold, cc1.exe-2.95 didn't crash any more.
If the problem is indeed due to memory corruption, then using Unixy
sbrk doesn't really solve it, it just sweeps it under the carpet.
- Raw text -