Message-ID:	<MAPI.Id.0016.00333138303633303030303930303044@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 01:14:10 +0100 (DJG)
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

Eli Zaretskii wrote:

> On Sat, 26 Jun 1999 pavenis AT lanet DOT lv wrote:
>
> > cc1.exe, cc1plus.exe etc. are nothing else than large C
> > programs that doesn't use any very special hacks 
>
> This is probably true, but some surprises can still lurk in GCC's code.  
> For example, it uses obstack which could assume all kinds of assumptions 
> about memory addresses to manage memory efficiently.

I have continued my search for the error details, and now it seems 
that CC1.EXE 2.7.2.1 for some odd reason sometimes jumps to
slightly wrong addresses! According to the traceback anyway,
we have:

1) CC1 calls _obstack_free() in the last call. That's wrong, it should
not call _obstack_free() normally. Instead, it should call
obstack_free() (without underscore, because __GNUC__ is defined).
In _obstack_free(), the parameters are probably wrong,
because it's the wrong routine, and CC1 crashes.

2) CC1 calls 0x1017 in the last call. This is outside the program.
oballoc()+0x20 tries to call _obstack_newchunk() but for some
odd reason it jumps to 0x1017 and crashes.

3) CC1 calls 0x8d3 in the last call. The same observation as in 2).

4) CC1 jumps into a local textstring (within obstack.c I think),
and tries to execute the data. It doesn't succeed and crashes.

I wonder how this can happen. Seems like the routines move
around somewhat in memory! Could the win3.11 DPMI server
rearrange data and code if there was a strange bug in win3.11?

> > 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?

Yes, I can do that in a day or so, and I will send a report then
how it went.

As an experiment, I rewrote malloc, free and realloc from scratch again,
and used DPMI-calls 0x501, 0x502 and 0x503 in a straight-forward
manner.

In PMODE V1.2, everything worked well for small C-programs, 
and if I tried to compile a large C-program, 0x501 did not succeed. 
But that was expected, because PMODE V1.2 only supports
120 memory blocks or so.

In win3.11, everything worked ok for small programs, but if I used
my 3-program sequence and a C-program with lots of "static" variables
in the beginning, CC1 crashed, in the same manner as usual.
There were no error messages from DPMI-calls 0x501, 0x502, 0x503.

Then, I removed DPMI-calls 0x502 and 0x503 (they are not really needed),
and only kept 0x501. Interestingly, CC1 still crashed in win3.11
in the usual way.

So, in my homemade CC1, I have removed malloc.c entirely,
and sbrk is only used initially, by crt0.S. CC1 still crashes in odd
places, and I only use DPMI-call 0x501 (one for each malloc call).
However, obstack.c is still in use, maybe there is something
wrong there. But only in win3.11? Only sometimes?

Finally, I also removed DPMI-call 0x501. Instead, I allocate a
big 16 Mbyte buffer the first time malloc is called, and then I use
it for subsequent memory requests. DPMI memory-calls are thereby 
totally bypassed until CC1 exits. This approach works.
I even had malloc to return new addresses in reversed order,
to check the block-order-sensitivity of CC1. It still works.

Then I would suspect the win3.11 DPMI server again.
If DPMI-calls are not used, or if PMODE or CWSDPMI are used,
CC1 2.7.2.1 runs perfectly. However I think I had problems
with CC1 2.8.1 both in DOS box and in plain DOS mode
(CWSDPMI r3), but I will check that again later. 

For your information, I found a crash report in the djgpp-list archive,
from 14 April 1998, titled "gcc crash". The program version
seems to be CC1.EXE 2.7.2.1 with DJGPP 2.01. Maybe it's
the same error here, because the traceback looks rather
familiar: error in flow.c, however the CS-, DS-limits etc. are
different compared to my tracebacks.

Thanks for any ideas,

Erik

- Raw text -