Date: Mon, 21 Jun 1999 19:18:53 +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 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 Mon, 21 Jun 1999, Erik Berglund wrote: > Perhaps it would be a help to have the source > code to gcc 2.95, snapshot 990616, for both gcc and libc, is it available > from somewhere? Andris has a link to it here: http://www.lanet.lv/~pavenis/djgpp.html (You will also need a script to patch the sources, read the instructions on the above page.) > I mean un-intentionally uninitialized, maybe someone forgot to > assign a value to a stack variable before it was used in the program. Yes, but how is this relevant to the crash in `free'? `free' should have nothing to do with stack variables, since stack space isn't allocated by `malloc', it is `sbrk'ed at program startup time in its entirety. > You could always catch some of these problems with the -Wuninitialized > switch to gcc, but not for structs, arrays, unions, volatiles or variables > whose size is other than 1, 2, 4 or 8 bytes. Is there another way to check > through all source code in gcc and libc for such problems? libc is built with a very stringent set of switches, so I doubt that such problems could evade us. As for GCC, I don't know what switches are used during its compilation, but if it doesn't use at least -Wall, you will probably see gobs of warnings if you turn on additional -Wxxx switches. And since GCC's sources are so large, it will be impractical to check by hand. Anyway, I can hardly believe stack variables have something to do with this problem, see above. > And can the few modules written in assembler in gcc be checked, too? Are there assembly source files in GCC? I don't remember. > I you want to reproduce the error on your site, it would probably be > sufficient to boot up win3.11 together with my saved system .zip-file. I don't have Windows 3.11 installed; never did. I only have 3.1. > 1) In gcc 2.7.2.1 (my original posting), gcc crashes at a different place, > at __obstack_free + 0x1c, (%eip=0xef7f4) on line 306 in obstack.c: > > plp = lp->prev; > > because lp=472450h (%edx), and that's probably outside the scope. I don't think that ``outside the scope'' (i.e. beyond the DS limit) is the problem here. If it were, you would have seen a GPF, not a Page Fault. Page Fault means something different---that the address in lp was somehow uncommitted, probably by Windows itself, like what CWSDPMI does when it uncommits the null page, to support NULL pointer protection. Error code 4 means that the exception happened because the program was trying to read from that address, which is consistent with the above line, since lp is on the right side of the equals sign. The question is: how come GCC needed to reference that address? Was that address ever valid one, or perhaps GCC somehow overwrote the variable during its run? > 2) I wonder about the segment limits for %cs, %ds, %es, %ss in > the crash dump from 14 Jun 1999. 0xfffeffff, isn't that a strange > value? No, this is how Windows DPMI server behaves. Look at the base address, you will see that its high bit is set also (it begins with 8).