Hi, The problem on windows seems to be the same issue, I'm getting seg faults in sp_object_repr_build_tree at the gpointer newobj = g_object_new(type, 0); call. type has a value of 55128808.
will keep looking into it.
John
--- MenTaLguY <mental@...3...> wrote:
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:2730I 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
ATTACHMENT part 2 application/pgp-signature name=signature.asc
__________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail