From: invalid AT erehwon DOT invalid (Graaagh the Mighty) Newsgroups: comp.os.msdos.djgpp Subject: Re: Strange behavior of compiler. Organization: Low Charisma Anonymous Message-ID: <3b351ccb.105323139@news.primus.ca> References: X-Newsreader: Forte Free Agent 1.11/32.235 Lines: 89 Date: Sat, 23 Jun 2001 22:53:22 GMT NNTP-Posting-Host: 207.176.153.154 X-Complaints-To: news AT primus DOT ca X-Trace: news2.tor.primus.ca 993336857 207.176.153.154 (Sat, 23 Jun 2001 18:54:17 EDT) NNTP-Posting-Date: Sat, 23 Jun 2001 18:54:17 EDT To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com On Thu, 21 Jun 2001 16:20:59 +0300 (IDT), Eli Zaretskii 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.