Date:	Fri, 18 Jun 1999 10:10:58 +0300 (WET)
From:	Andris Pavenis <pavenis AT ieva01 DOT lanet DOT lv>
To:	Erik Berglund <erik2 DOT berglund AT telia DOT com>
cc:	djgpp-workers AT delorie DOT com
Subject:	Re: Re: gcc-crash - and a possible solution
In-Reply-To:	<MAPI.Id.0016.00333138303633303030303930303039@MAPI.to.RFC822>
Message-ID:	<Pine.A41.4.05.9906180951370.104692-100000@ieva01.lanet.lv>
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

On Fri, 18 Jun 1999, Erik Berglund wrote:

> 
> Hi,
> sorry if you've received multiple copies of this message,
> but I tried to send it to djgpp-workers AT delorie DOT com, and it didn't
> seem to work. Could you please forward it to the list after
> reading it?
> 
> Andris Pavenis wrote:
> 
> > So I suggest to try this version. I'll make at least C and C++ 
> > compiler binaries available at 
> >           http://www.lanet.lv/~pavenis/djgpp.html
> 
> Now I have downloaded the C binaries (version 2.95, 16 Jun snapshot).
> I then replaced my old c:\djgpp\cc1.exe with the new one
> (cc1.exe from 17 Jun 1999, 2:15, 2575576 bytes).

Bad idea. It's not recommended to mix gcc versions in such way. Readme
file says to uninstall previous version especially if it is older than
gcc-2.8.0. However this is for future (best is to install compiler
correctly) and is certainly not a source of current problem

Unfortunatelly I cannot say anything more. I can only try to link cc1 with
some memory debugger (I have mix of old fortify and libmmalloc.a I used
sometime earlier to debug rhide) 

One other idea could be trying to build some test example which allocates
and deallocates memory intensively. Perhaps it would be easier to check
these things as with cc1.


Some information about binaries of gcc-2.95 19990615 which were used for
these tests:
	build using unmodified DJGPP-2.02 (took from local Simtelnet
	mirror) and binutils-2.8.1. gcc-2.8.1 was used for bootstrapping.


> 
> Before too long, I was able to reproduce the error, in almost the same
> way as I used for 2.7.2.1. Here comes the symified register dump:
> 
> Exiting due to signal SIGSEGV
> Page fault at eip=00175777, error=0004
> eax=00d7bba0 ebx=00362ec4 ecx=00362ec4 edx=00f1c908 esi=00363ebc
> edi=0035eee8
> ebp=00330b80 esp=00330b74 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=0001e380  limit=0000ffff
> gs: sel=00bf  base=00000000  limit=0010ffff
> ss: sel=00af  base=81043000  limit=fffeffff
> App stack: [00332000..001b2000]  Exceptn stack: [001a0d40..0019ee00]
> 
> Call frame traceback EIPs:
>   0x00175777 _free+119
>   0x00173755 _obstack_free+49
>   0x000dbcb6 _reload+3730
>   0x000cdc85 _global_alloc+1901
>   0x0000b100 _rest_of_compilation+3480
>   0x00161c54 _finish_function+188
>   0x0014e4fe _yyparse+3366
>   0x00009ae1 _check_global_declarations+3357
>   0x0000d8df _main+4179
>   0x00174b8a ___crt1_startup+174
> 
> Hope this information helps. 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.
> 
> Please let me know if you want more register dumps or 
> any other information.

As I said there seems to be some memory (corruption???) related problem.
I think it would be best to try to reproduce it in some test example
rather than studying interior of gcc.

Andris

- Raw text -