Date: Thu, 21 Jun 2001 16:20:59 +0300 (IDT) From: Eli Zaretskii 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: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Precedence: bulk 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?