Mail Archives: djgpp-workers/1999/06/23/05:33:21
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.
I don't think this is wrong. Assuming the DS limit is 0xfffeffff,
0xfffeffff - 0xfff7ffd0 = 458799 (decimal), which is quite a lot. So
why do you think this offset is wrong?
Note that if this offset is beyond the DS limit, dereferencing it
would trigger a GPF and crash cc1. The fact that you don't see a GPF,
but rather a Page fault, and that it doesn't happen until some time
into the compilation, indicates that things are more complicated.
> 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.
This is consistent with the suspicion that the Windows DPMI server is,
at least indirectly, the key factor to unlocking the problem.
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.
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?
> So we can stop looking for answers inside GCC, there is nothing
> wrong with this code I think.
I don't think we can clear cc1 of any guilt at this point, at least
not yet. The fact is that you don't have any other program that
crashes like that. If the problem is with the stack pointer, then any
other program which begins with such a stack would crash. Did you try
to run other large DJGPP programs in this situation, and if so, did
they crash as well?
If not, it is possible that cc1 assumes something about the memory
layout that doesn't hold in your case. In any case, if cc1 is the
only program that crashes, we have no choice but to use it as the test
bed for this problem.
> However, the stack allocation mechanism works perfectly just until
> CC1.EXE is invoked by DOS.
Please explain this observation. What exactly did you see that led
you to the conclusion that the stack allocation works until cc1 is
invoked.
> Something strange happens between
> start of the stub loader and start of main() in CC1.EXE
Note that the run-time stack of DJGPP programs is allocated by crt0.S,
not by the stub. The stub only allocates memory for the sections read
from the COFF image.
> I will enclose here my special 3-program sequence. It doesn't do
> anything useful, just some mapping. The code itself works perfectly.
>
> #include <dpmi.h>
> uchar locbuf[2][640*480*3];
> int main(int argc,char *argv[]) {
> static __dpmi_meminfo meminfo;
> meminfo.address = 0xfd000000;
> meminfo.size = 8*(1024*1024);
> if (__dpmi_physical_address_mapping(&meminfo) < 0)
> exit1("? initpci error");
> return(0);
> }
Does the problem ever happen if you don't invoke programs that call
__dpmi_physical_address_mapping, like if you run simple applications?
- Raw text -