bonobo_window_construct() trouble...

[Jaka Mocnik <jaka gnu org>]

hello!

I have encountered a bug in GGv - making it crash at startup - that only
happens on some people's installations. As I couldn't reproduce on my
system, I got an account from someone who suffered from this and behold:
it seemed to me that a call to bonobo_window_construct() is trashing
some of the memory. thorough inspection shows this in
bonobo_window_construct():

(gdb) print *ui_container
$5 = {base = {base = {g_type_instance = {g_class = 0x8083418},
      ref_count = 2, qdata = 0x0}, priv = 0x8083cb0,
      object_signature = 44786, servant = {_private = 0x8083cc0,
      vepv = 0x80834f0}, dummy = 0, corba_objref = 0x8083d30,
      servant_signature = 12206}, priv = 0x8083d58}
(gdb) next
568		bonobo_object_unref (BONOBO_OBJECT (ui_container));
(gdb) print *ui_container
$6 = {base = {base = {g_type_instance = {g_class = 0x8083418},
      ref_count = 2, qdata = 0x0}, priv = 0x8083cb0,
      object_signature = 44786, servant = {_private = 0x8083cc0,
      vepv = 0x80834f0}, dummy = 0, corba_objref = 0x8083d30,
      servant_signature = 12206}, priv = 0x8083d58}
(gdb) next
570		if (title)
(gdb) print *ui_container
$7 = {base = {base = {g_type_instance = {g_class = 0x409b02d8}, 
      ref_count = 1083900632, qdata = 0xaaaaaaaa}, priv = 0xaaaaaaaa, 
      object_signature = 2863311530, servant = {_private = 0xaaaaaaaa, 
      vepv = 0xaaaaaaaa}, dummy = 2863311530, corba_objref = 0xaaaaaaaa,
      servant_signature = 2863311530}, priv = 0x30}

so it seems that a call to bonobo_object_unref () is destroying the
ui_container although it has a reference count of two...

how come?

now, this is from bonobo_object_unref():

Breakpoint 5, bonobo_object_unref (obj=0x8083c70) at bonobo-object.c:282
282	{
(gdb) print *obj
Attempt to dereference a generic pointer.
(gdb) next
287		if (!object)
(gdb) next
290		g_return_val_if_fail (BONOBO_IS_OBJECT (object), NULL);
(gdb) next
292		ao = object->priv->ao;
(gdb) next
293		g_return_val_if_fail (ao != NULL, NULL);
(gdb) print *ao
$9 = {ref_count = 1, immortal = 0, objs = 0x8057f08}
(gdb) print *object
$10 = {base = {g_type_instance = {g_class = 0x1}, ref_count = 0, 
       qdata = 0x8057f08}, priv = 0x11, object_signature = 134757536,
       servant = {_private = 0x409b01e8, vepv = 0x0}, dummy = 49,
       corba_objref = 0x407cf4f8, servant_signature = 2}
(gdb) next
294		g_return_val_if_fail (ao->ref_count > 0, NULL);
(gdb) print *object
$11 = {base = {g_type_instance = {g_class = 0x1}, ref_count = 0, 
       qdata = 0x8057f08}, priv = 0x11, object_signature = 134757536,
       servant = {_private = 0x409b01e8, vepv = 0x0}, dummy = 49,
       corba_objref = 0x407cf4f8, servant_signature = 2}
(gdb) print object
$12 = (BonoboObject *) 0x8083ca0
(gdb) print obj
$13 = 0x8083c70

notice the strange values of *object? why? well, although it is a bit
strange and completely impossible to explain this from looking at the
bonobo_object_unref() code, obj is at address 0x8083c70 (which is the
valid address of the ui_container being unrefed), while object is at a
48 bytes higher address, although the only statement affecting the value
of object is "BonoboObject *object = obj;".

even stranger - in the next debugging session, I discover that the
address change of object happens after "ao = object->priv->ao;"?!

292		ao = object->priv->ao;
(gdb) print object
$21 = (BonoboObject *) 0x8084e90
(gdb) next
293		g_return_val_if_fail (ao != NULL, NULL);
(gdb) print object
$23 = (BonoboObject *) 0x8084ec0

now this really puzzles me: can someone help?

regards,
	jaKa

-- 

email: jaka gnu org
w3:    http://pluton.ijs.si/~jaka