Date: Sun, 24 Jun 2001 10:35:20 +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: <3b351ccb.105323139@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 Sat, 23 Jun 2001, Graaagh the Mighty wrote: > >> 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. My advice, based on lots of debugging experience, is to not trust the traceback so much, once you see a strange number such as 0x1fc00000 in it. > >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 Not true. Why do you insist speculating instead of stepping with a debugger into the code, and seeing what actually happens? Speculating about what code will do is the most inefficient method of debugging. > >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. It doesn't matter; -gstabs+ is better even without optimizations, when you have tricky bugs like this one. > >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? See above; this isn't hard evidence. Single-stepping the program under a debugger would be.