Date:	Thu, 21 Jun 2001 16:20:59 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	djgpp AT delorie DOT com
Subject:	Re: Strange behavior of compiler.
In-Reply-To:	<3b31a377.174815003@news.primus.ca>
Message-ID:	<Pine.SUN.3.91.1010621161027.10384E-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

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.

>   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.  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.
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.

In other words, I agree with Hans-Bernhard: you should run the program 
under a debugger, single-step it where bar is called, and see whether you 
wind up inside bar, and if so, what line there is the last one executed 
before you hit SIGSEGV.  That's the most efficient way to find the 
problem.

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.

> So, maybe the malloc arena, the stack, or something is getting
> trashed? But it's dying *invoking* foo, not *returning* from it

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?

- Raw text -