delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/1999/06/20/03:58:26

Date: Sun, 20 Jun 1999 10:55:35 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Andris Pavenis <pavenis AT ieva01 DOT lanet DOT lv>
cc: Erik Berglund <erik2 DOT berglund AT telia DOT com>, djgpp-workers AT delorie DOT com
Subject: Re: Re: gcc-crash - and a possible solution
In-Reply-To: <Pine.A41.4.05.9906180951370.104692-100000@ieva01.lanet.lv>
Message-ID: <Pine.SUN.3.91.990620105501.16821O-100000@is>
MIME-Version: 1.0
Reply-To: djgpp-workers AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

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 -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019