Re: Optimization problems with g++ 3.4

[Paul Pluzhnikov]

marc-oliver.gewaltig@web.de (Marc-oliver Gewaltig) writes:

>    I mean, that I do not get a call-stack which roots in main(), but only
>    one level is present. When using -O3, however, I do have a full call 
>    stack visible in gdb.

And that (crash) stack trace is?

> 6. Needless to say that the point of seg-fault moves away from my attempts to
>    catch it with "traditional" methods, like assertions and debug messages. 

Did you try valgrind?

> Has enybody encountered something similar?

Sure. Many stack corruption bugs exhibit all of the behaviours you listed.

> How likely is it that the bug is in our code?

Quite likely.

> (remember, the crash is platform specific)

So what? 
The bug is likely *also* happening on Solaris, but just happens
not to touch anything important.

> Can it be that there is a i686 specific optimization problem?

Could be, but not very likely.

Stack corruption in general is often quite difficult to catch,
unless it is reproducible [1]. One tool that might help with
this is Insure++ from ParaSoft.

[1] If the crash is reproducible under gdb, you can catch it
as follows:

- Assuming it happens on 101st call to foo()
- Assuming that the stack is "good" when foo() is entered, but
  "bad" by the time of the crash.

(gbd) b foo          ## break on foo
(gdb) ignore 1 100   ## ignore first 100 crossings
(gdb) run
## BP1 is hit
(gdb) bt             ## call stack should be "good" at this point
(gbd) p/x $ebp
$1 = 0xbfff...
(gdb) x/4x $ebp      ## values of previous EBP, return address,
                     ## arg0 and arg1

## Now you want to know who "steps on" prev-EBP and/or return address

(gdb) watch *(int **)$1        ## Hardware watchpoints 2, 3
(gdb) watch *(int **)($1+4)
(gdb) cont   

## If watchpoints 2 or 3 fire, you'll be looking at the "guilty" code.

Cheers,
-- 
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.