Message-ID: <MAPI.Id.0016.00333138303633303030303930303045@MAPI.to.RFC822>
In-Reply-To: <Pine.SUN.3.91.990627170813.5761C-100000@is>
References: Conversation <B0000091956 AT stargate DOT astr DOT lu DOT lv> with last message <Pine DOT SUN DOT 3 DOT 91 DOT 990627170813 DOT 5761C-100000 AT is>
Priority: Normal
X-MSMail-Priority: Normal
X-Priority: 3
To: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Cc: djgpp-workers AT delorie DOT com, sandmann AT clio DOT rice DOT edu
MIME-Version: 1.0
From: "Erik Berglund" <erik2 DOT berglund AT telia DOT com>
Subject: Re: Re: gcc-crash - and a possible solution
Date: Tue, 29 Jun 99 04:12:16 +0100 (DJG)
Content-Type: text/plain; charset="ISO-8859-1"; X-MAPIextension=".TXT"
Content-Transfer-Encoding: 7bit
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
Precedence: bulk


Eli Zaretskii wrote:

On Sat, 26 Jun 1999 pavenis AT lanet DOT lv wrote:

> > 2)   binaries of gcc-2.95 19990615 You tested before where linked
> >       with unmodified DJGPP-2.02. Current binaries (same place)
> >       of gcc-2.95 19990623 are linked with 16 June CVS version of
> >       DJGPP. However I doubt if there will be so serious changes in
> >       related parts of libc.a

> Actually, there was one change that might be related: malloc mixed signed 
> and unsigned in several places.  So I'd suggest to see if the latest 
> binaries still have this problem.  Erik, could you please do that?

I'm sorry to say, I got a crash with the new CC1.EXE from 25 Jun 1999,
16:49, 1858978 bytes, after running my 3-program sequence.
Register dump follows:

Page fault at eip=00175a33, error=0004
eax=00001000 ebx=00372f14 ecx=00373f1c edx=00dcfad0 esi=00373f1c
edi=0018faec
ebp=003318ec esp=003318e0 program=C:\DJGPP\BIN\CC1.EXE
cs: sel=00a7  base=81043000  limit=fffeffff
ds: sel=00af  base=81043000  limit=fffeffff
es: sel=00af  base=81043000  limit=fffeffff
fs: sel=0087  base=0001e3e0  limit=0000ffff
gs: sel=00bf  base=00000000  limit=0010ffff
ss: sel=00af  base=81043000  limit=fffeffff
App stack: [00332000..001b2000]  Exceptn stack: [001a2810..001a08d0]
 
Call frame traceback EIPs:
  0x00175a33   _free+243
  0x00173811   _obstack_free+49
  0x000785f7   _bitmap_release_memory+51
  0x000c7673   _regset_release_memory+11
  0x0000b5a5   _rest_of_compilation+4669
  0x00161d10   _finish_function+188
  0x0014e59a   _yyparse+3366
  0x00009ae1   _check_global_declarations+3357
  0x0000d8df   _main+4179
  0x00174cf0   ___crt1_startup+204

I also found a small bug in my previous letter :),
correction as follows:

CC1.EXE 2.7.2.1 does call _obstack_free(), so it actually
calls the right address in case 1). Probably I've
defined __STDC__ to the wrong value when I rebuilt
CC1.EXE, but the original CC1.EXE from 19 Oct 1996
calls _obstack_free(), I saw it when I examined the
binary file.

Erik