Bug#224811: More data, advise requested.
I've just tried to reproduce this bug with g++-3.4 (GCC) 3.4.0 20040403
from experimental and the latest gdb it appears to have fixed it, albeit
with lots of 0x00000000 in ?? () type frames appearing in the backtrace
Running the program having compiled it with the latest g++ 3.3 ends in
#60 0x4f0dda16 in _dl_map_object_deps () from /lib/ld-linux.so.2
Previous frame inner to this frame (corrupt stack?)
also has lots of 0x00000000 in ?? () but also has frames like
0xbffff6d4 in ?? ()
Finally, I tried using g++-2.95. Lots of 0x00000000 in ?? (), but it
does point to the right location.
The LD_ASSUME_KERNEL removes the odd frames from the stack trace, but it
seems to be a bug in g++ as well.
(One extra data point, since reporting I've installed libc-i686, but
this doesn't appear to affect the results)
Should this remain assigned against libc6 as it appears to be NPTL
related[1], or should I file a
bug against g++-3.3 as it's the only compiler that completely fails to
produce a usable stacktrace with NPTL[2] ?
[1] What else does LD_ASSUME_KERNEL=2.4.xx do?
[2] See [1].
Thanks,
Euan.
Reply to: