Mail Archives: djgpp-workers/1999/06/23/12:06:17
> On Tue, 22 Jun 1999, Erik Berglund wrote:
>
> > Normally, when all goes well, I will consistently get:
> >
> > &p = 0x0015a630
> >
> > which is a very reasonable location for beginning of the stack.
> >
> > However, when I've run my special 3-program sequence,
> > to trig the gcc-crash, I get:
> >
> > &p = 0xfff7ffd0
> >
> > which is a totally wrong place for the stack, IMHO.
What has happened is that that your DPMI provider has for some
bizzare reason chosen to return memory blocks in non-increasing
order. So the second memory request from DPMI gets stuffed in
some memory area virtually right below "0", which we access
via adress wrap. While this is bizzare, it's completely
legal.
This theoretically should work, but there are problems with
signed/unsigned arithmetic in our libc and applications which
really don't work with a 4Gb address space. This is not
tested under any other environemnts!
> > Important notice: Once I get the (&p = 0xfff7ffd0) value,
> > I will consistanly get that value for CC1.EXE, and my own little
> > DJGPP-programs will also start to get strange
> > stack pointer values, for instance it may jump up
> > to a new value, approximately 0x70000 higher.
>
> But we still need to understand whether the crash happens because of
> Windows, or because cc1 or the library does something that breaks
> under these curcumstances.
I'm pretty sure it's because of signed/unsigned problems in the
applications (like gcc and/or malloc).
> Charles, I think you sent me a program that printed the memory handles
> in use. I cannot find that program now. Could you tell me where to
> look, or how to write it? Perhaps if we look at the memory layout we
> could get a hint on what's going on?
It's actually stored in crt0 in some structure - some of the libc
routines use it
- Raw text -