Mail Archives: djgpp/2001/06/23/19:00:25
On Thu, 21 Jun 2001 16:20:59 +0300 (IDT), Eli Zaretskii
<eliz AT is DOT elta DOT co DOT il> sat on a tribble, which squeaked:
>
>On Thu, 21 Jun 2001, Graaagh the Mighty wrote:
>
>> I think I've found a bug in gcc 2.95.2.
>
>It's possible. However, to demonstrate that, you will have to show code
>produced by the compiler near the call to bar via a pointer, which
>exhibits the bug. Unless the code clearly shows that a wrong address is
>used to call the function, it's not a compiler bug: addresses don't get
>changed magically, except on faulty hardware.
Faulty hardware isn't as consistent as this was.
>
>> printf("%x\n", (int)foo);
>> if (foo()) {
>> ...error message...
>> return -1;
>> }
>> ...rest of job...
>> }
>>
>> The result?
>>
>> 3a30
>> 3a30
>> Exiting due to signal SIGSEGV
>> Page fault at eip=01fc0000, error=0004
>> eax=01fc0000 ebx=ffffffff ecx=0000d854 edx=00004000 esi=000000ff
>> edi=00000000
>> ebp=004a9fb0 esp=004a9cc4 program=D:\QUICKM\BWLSM.EXE
>> cs: sel=00a7 base=83be4000 limit=ffa02fff
>> ds: sel=00af base=83be4000 limit=ffa02fff
>> es: sel=00af base=83be4000 limit=ffa02fff
>> fs: sel=0087 base=0000d830 limit=0000ffff
>> gs: sel=00bf base=00000000 limit=0010ffff
>> ss: sel=00af base=83be4000 limit=ffa02fff
>> App stack: [004aa000..0042a000] Exceptn stack: [00095428..000934e8]
>>
>> Call frame traceback EIPs:
>> 0x01fc0000 0x1fc0000
>> 0x0000178b _main+275, line 195 of bwlsm.c
>> 0x00057b7a ___crt1_startup+174
>>
>> In other words, foo is 0x3a30 at the printf line, and 0x01fc0000 the
>> line right after.
>
>This last assertion needs to be proven, and you didn't present any
>evidence to its validity.
See the traceback? Jumped from the line "if(foo()) {" directly to
0x1fc00000. With no aggressive optimizations on. Ergo, the jump in
question really must be the foo(). Which means foo was 0x1fc00000,
although it was 0x3a30 the line before.
>The fact that the last symified line in the
>traceback is where bar is called does not prove that the address is in
>error: the crash could have happened inside bar, _after_ it was called.
Only if it happened right at the beginning before anything else
whatsoever, certainly anything with side-effects, or
-fomit-frame-pointer was on. Neither was true.
>If the bug which causes this scroggs the run-time stack, you could have
>some weird garbage in the traceback, just like you show above.
A stack smash will usually trash the stack completely, and you'll
usually get a traceback that starts and ends in the middle of nowhere
-- if you get one at all, that is.
>Oh, and be sure to compile and link with -gstabs+, otherwise the
>optimizations could interfere with your need to know in what source line
>are you at any given moment.
What optimizations? This was reproduced with optimizations turned off.
>I think you jump to conclusions too early. Do you really have hard
>evidence that foo was not entered, or is that just a speculation?
Its absence on the traceback with -fomit-frame-pointer off and an
otherwise-normal traceback?
--
Bill Gates: "No computer will ever need more than 640K of RAM." -- 1980
"There's nobody getting rich writing software that I know of." -- 1980
"This antitrust thing will blow over." -- 1998
Combine neo, an underscore, and one thousand sixty-one to make my hotmail addy.
- Raw text -