Mail Archives: djgpp/2001/06/24/03:33:43
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.
- Raw text -