Date: Wed, 23 Jun 1999 11:27:59 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: Erik Berglund cc: pavenis AT lanet DOT lv, djgpp-workers AT delorie DOT com, Charles Sandmann Subject: Re: Re: gcc-crash - and a possible solution In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Precedence: bulk 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 > 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?