delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/1999/06/26/08:07:07

From: pavenis AT lanet DOT lv
Message-ID: <B0000091956@stargate.astr.lu.lv>
To: "Erik Berglund" <erik2 DOT berglund AT telia DOT com>, djgpp-workers AT delorie DOT com
Date: Sat, 26 Jun 1999 15:06:37 +0300
MIME-Version: 1.0
Subject: Re: Re: gcc-crash - and a possible solution
In-reply-to: <MAPI.Id.0016.00333138303633303030303930303043@MAPI.to.RFC822>
References: <9906242330 DOT AA14501 AT clio DOT rice DOT edu>
X-mailer: Pegasus Mail for Win32 (v3.11)
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

I still suggest to try to make a smaller test example that 
reproduces the problem:

gcc is too large for such test example;

cc1.exe, cc1plus.exe etc. are nothing else than large C
programs that doesn't use any very special hacks (at least
I haven't saw such as far as I have looked). Therefore I
suspect the problem maybe with libc.a and as result perhaps could 
be reproduced in smaller example. 

So my suggestions:
1)	try modifying test example I initially sent (filling memory at
	allocation and testing it at deallocation), try to use also 
      realloc()

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

3)   Try to spawn test program from another one (maybe in more
      than level). Also different allocation types should be used

If You'll succeed to reproduce  these crashes with small example I 
think it's much more likely they will be fixed. Of course ths list 
above is very far from being complete


On 26 Jun 99, at 2:32, Erik Berglund wrote:
> 
> > > I did some experimenting and printed out the addresses coming from
> > > malloc-calls in CC1.EXE, there were several hundreds of them, and
> > > some of them were below 2 Gbyte, and some were above 2 Gbyte,
> > > it all came out in a random fashion.
> >
> > Not unexpected if you get some dpmi blocks returned below the
> > original one.
> 
> No it's perfectly ok in theory, and malloc and CC1.EXE should work
> just as well for any pointer between 1 and 4 Gbyte-1, in theory.
> 
> Maybe there is an error in win3.11:
> 
> Too many DPMI-requests with unordered blocks in one 
> program could perhaps overflow the internal Windows tables,
> and it's not indicated in the CF-flag from the DPMI-call.
> That's just a theory. It might also be malloc, realloc or GCC.
> 
> Just some other experiments that I did recently:
> 
> 1) I made an "improved" malloc.c (malloc, realloc, free),
> which calls the old malloc, realloc, free, but also inits 
> malloc'ed data to 0 and also copies the old
> data in realloc to the new address. I rebuilt CC1.EXE
> with it and it seems to work so far...

Then try to fill malloced memory with something stupid (eg. 0xA3)
and see whether it changes anything. But don't forget to use 
default sbrk instead of the way which worked earlier for You.

> 
> 2) I rewrote malloc.c (malloc, realloc, free) from scratch,
> so initially I allocate 16 Mbyte (using the old malloc),
> and then just return an increasing pointer to the application.
> free doesn't do anything at all. I rebuilt CC1.EXE
> and everything seemed to work with this approach as well.

Not nice idea. I'm afraid CC1.exe may run out of memory for 
larger programs.

> 
> Now I think I will test 1) for a few days and see what's happening.
> 


Andris

- Raw text -


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