Date: Wed, 23 Jun 1999 11:30:10 +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 Note that I cc: this and following messages to Charles Sandmann, in the hope that he could help us figure out these crashes. On Tue, 22 Jun 1999, Erik Berglund wrote: > I was wondering about the "e", shouln't it be 0xffffffff instead of > 0xfffeffff? No. The former is -1, which disables memory protection. The latter is a valid limit, it just looks weird. > And I wonder why CC1.EXE sets such a high limit, and thereby effectively > disables the memory protection? When you use non-Unixy sbrk, the limit might need to be high because the DPMI server allocates memory in several non-contiguous chunks that might be far apart in the linear address space. But that doesn't disable memory protection because parts of the address space that don't belong to any allocated chunk will trigger a Page Fault, just like the one you see. > I made a small test program which reads from an invalid address, to get > a "normal" crash dump. I got, for %cs (Windows DPMI was used): > > %cs sel=0xb7, base=0x815f3000, limit=0x000affff > > Here, the %cs-limit has a more "normal" value, which I can understand. > Why does CC1.EXE have to set the limit all the way up to > the "unnormal" value 0xfffeffff? Because cc1 allocates more memory at startup than small test programs (cc1 has much more code and data), and the Windows DPMI server needs to find enough of free memory to satisfy the requests. Evidently, the small test program would settle for a single chunk, while cc1 needs several non-contiguous chunks. I have the same situation with several large programs on Windows 95, but they never caused any crashes. So this ``unusual'' limit is not the immediate cause of the crash. Some other factor must be at work here. But once again, I don't think stack is your problem here, since `free' has nothing to do with stack, unless cc1 overflowed its run-time stack. However, the stack overflow hypothesis doesn't seem to be valid here, since (1) the latest EGCS binary, which has a 1.5MB stack, also crashed in the same place in `free', and (2) the registers' dump that you posted shows a very low stack usage, about 8KB. So I think the problem is not with stack but with the heap. The heap is the first place to look for problems when the crashes are inside `malloc' or `free'.