Mail Archives: djgpp-workers/1999/06/21/12:21:34
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).
- Raw text -