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
Line numbers help too:
> #0 0x0000020000a40b68 in g_type_is_a (type=3D541535280, iface_type=3D483=
> 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=3D0x12047c2=
> repr=3D0x1204eef10) 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
It would be instructive to set a breakpoint on sp_root_get_type() and
make sure that is behaving as it ought.
Get latest updates about Open Source Projects, Conferences and News.