Mail Archives: djgpp-workers/1999/06/26/08:07:07
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 -