Re: Activation problems

[Seth Nickell <snickell stanford edu>]

Another piece of data...

I get garbage data back (w/ no errors that I know how to find...) if I
do:

	translator = Bonobo_Unknown_queryInterface (translator_object,
"IDL:Bonobo/Unknown:1.0", &ev);

    or
	translator = Bonobo_Unknown_queryInterface (translator_object,
"IDL:Garbage/Interface:1.0", &ev);

instead of trying to query for my interface
"IDL:GNOME/StorageTranslator:1.0".

-Seth

On Tue, 2003-07-29 at 15:54, Seth Nickell wrote:
> 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