Message-ID:	<MAPI.Id.0016.00333138303633303030303930303046@MAPI.to.RFC822>
In-Reply-To:	<B0000092184@stargate.astr.lu.lv>
References:	Conversation <Pine DOT SUN DOT 3 DOT 91 DOT 990627170813 DOT 5761C-100000 AT is> with last message <B0000092184 AT stargate DOT astr DOT lu DOT lv>
Priority:	Normal
X-MSMail-Priority:	Normal
X-Priority:	3
To:	pavenis AT lanet DOT lv
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 23:27:24 +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

Andris Pavenis wrote:

> It only means that the actual problem seems to be not fixed in 
> CVS version of DJGPP up to June 16th. So unless we'll be able to 
> found the real reason why it happens I'm afraid it will be stay so.
> 
> This is reason why I suggest to try to reproduce the problem with 
> smaller test example. 
> 
> Also it would be usefull to test the same on a different system. 
> Maybe somebody can try that on Win311. As I said before I don't 
> have Win311 on machine I could test that.

I've tried to reproduce the error in a small program, but it seems
to be difficult.

Nonetheless, I think I have some good news anyway:
I changed the "alloc-delta" in crt0.S from 64 kbyte to 1 Mbyte
(the amount that is allocated each time from DPMI),
and now everything works! Even with non-unixy sbrk!

I'm quite happy with this workaround, so I will use it now
for a while and tell you if it didn't work in the long run.

Maybe the problem had something to do with memory
fragmentation in win3.11, so by decreasing the number
of DPMI-allocations, we put much less stress on the
win3.11 internal tables.

Also, I'd like to mention that the high value of %edx
(0x472450) in my original posting on 14 Jun 1999,
seems to be around 2 Mbyte too high to be valid.
%edx holds the "lp" variable in obstack.c (version 2.7.2.1),
line 332: 

plp = lp->prev;

The highest valid lp-value seems to be around 0x28a004,
and therefore we get a "Page fault" error 0004
when lp for some reason becomes 0x472450.

Thanks all for your help,

Erik

- Raw text -