Re: Activation problems

[Seth Nickell <snickell stanford edu>]

Hey Michael,

Didn't want to flood you if I'd done something silly... So here's a lot
more debug info. Backtrace attached... but it looks like the problem is
that Bonobo_Unknown_queryInterface is returning a totally bogus object
without complaint... consequently the "obj->connection" is some random
pointer location and hence the segfault.

> On Sun, 2003-07-27 at 02:51, Seth Nickell wrote:
> > This returns what *seems* like a valid object (at least, it isn't NULL
> > and its internal values seem at least remotely sane), no exception is
> > set. So now I call a method in my object...
> 
> 	Is the structure layout printed out by gdb the same as that in the
> header corba-object-type.h ?

Yes.

> 	Either way - there are seriously broken autotools things, such that if
> you include a .h file in a SOURCES line it throws away all dependency
> tracking for that directory; thus it's _possible_ that a simple make
> clean / make install in ORBit2 will fix the problem for you.

Nope.

> > Which blows up trying to ref the connection on the object, which is
> > NULL.
> 
> 	A stack trace ? we've done some things in this area recently to re-use
> connections etc. but it seems to work fine; and indeed, for an in-proc
> object, you shouldn't actually have a connection.
> 
> >  Any ideas what I'm doing wrong? (and maybe even if I am there's a
> > bug because it would be nice to have some sort of exception set
> > somewhere rather than a segfault)
> 
> 	Sure - it should never segfault; that's just broken :-) if we can do
> better detecting your problem in future we'll try too - possibly
> (somehow) a pointer to a BonoboObject has got returned (in-proc) instead
> of the BONOBO_OBJREF () but if you use GenericFactory it's unlikely that
> you'll get caught by that I think.

So here's what translator looks like (assigned the return value from
Bonobo_Unknown_queryInterface).

(gdb) p *translator
$5 = {parent = {interface = 0xbffff830, refs = -1073743824}, 
  connection = 0x80490b3, type_qid = 3221223536, profile_list =
0x4000c3b3, 
  forward_locations = 0x40016194, object_key = 0xbffff814, orb = 0x0, 
  adaptor_obj = 0x0}

I don't know about you, but I find -1073743824 refs to be slightly
suspicious. On the other hand, the object translator_object returned by
bonobo-activation that was passed into Bonobo_Unknown_queryInterface
looks valid (has a sensible number of refs, connection is NULL, type
looks looks reasonable, orb has a value set, etc):

(gdb) p *translator_object
$4 = {parent = {interface = 0x406e42d0, refs = 2}, connection = 0x0, 
  type_qid = 83, profile_list = 0x0, forward_locations = 0x0, 
  object_key = 0x0, orb = 0x8051f28, adaptor_obj = 0x806cca0}

So Bonobo_Unknown_queryInterface takes a valid object... and is
returning what looks like uninitialized data as a result.

-Seth

(gdb) bt
#0  0x406fc96a in g_object_ref (_object=0x80490b3) at gobject.c:1319
#1  0x40677a1e in link_connection_ref (cnx=0x80490b3) at linc-connection.c:57
#2  0x406beb83 in ORBit_object_get_connection (obj=0x80490b3)
    at corba-object.c:330
#3  0x406bcc32 in ORBit_small_invoke_stub (obj=0xbffff814, m_data=0x804a900, 
    ret=0x0, args=0x0, ctx=0x0, ev=0xbffff830) at orbit-small.c:615
#4  0x406bcb70 in ORBit_small_invoke_stub_n (object=0xbffff814, methods=0x0, 
    index=-2084014707, ret=0x0, args=0x0, ctx=0x0, ev=0x804e4b8)
    at orbit-small.c:571
#5  0x406cc115 in ORBit_c_stub_invoke (obj=0xbffff814, methods=0x804aa24, 
    method_index=0, ret=0x0, args=0x0, ctx=0x0, ev=0xbffff830, class_id=7, 
    method_offset=4, 
    skel_impl=0x8049488 <_ORBIT_skel_small_GNOME_StorageTranslator_startImport>) at poa.c:2492
#6  0x080493d3 in GNOME_StorageTranslator_startImport (_obj=0xbffff814, 
    ev=0xbffff830) at GNOME_StorageTranslator-stubs.c:13
#7  0x0804913f in main (argc=1, argv=0xbffff8b4)
    at translator-factory-test.c:58
#8  0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6
(gdb)