On Mon, 2004-08-16 at 14:02, Wolfram Quester wrote:
It was a live session, I didn't fake the gdb-call and run-command in my report :) Maybe the effect is due to a cunning g++-optimization, The results so far were with the original binary and the -dbg-libs.
That's what I meant. The weirdness was either stack corruption or side-effects of compiler optimizations.
Ok, now a new debug-build (noopt, nostrip) is ready but the backtrace is nearly the same:
Well, with the important difference that it is a believable call sequence, so I can be more confident the backtrace information is accurate.
Line numbers help too:
#0 0x0000020000a40b68 in g_type_is_a (type=541535280, iface_type=4836502576) at gtype.c:2730
I seem to recall that type is an index into an array, so both these values are far too large (unless they're now direct pointers)...
#1 0x00000001200daa74 in sp_object_repr_build_tree (document=0x12047c260, repr=0x1204eef10) at sp-object-repr.cpp:54
(since moved down a few lines:)
g_assert (g_type_is_a (type, SP_TYPE_ROOT));
So it looks like perhaps the types in question have not been properly registered somehow?
It would be instructive to set a breakpoint on sp_root_get_type() and make sure that is behaving as it ought.
-mental