[omniORB] OrbixNames-1.1c and omniORB (again)

[Duncan Grisby]

On Wednesday 31 January, Mark Borges wrote:

[...]
> omniORB: The object with the IR repository ID:
> IDL:omg.org/CosNaming/NamingContext:1.0 returns FALSE to the query
> _is_a("IDL:omg.org/CosNaming/NamingContext:1.0").  A
> CORBA::INV_OBJREF is raised.

> Obviously, I'm misunderstanding something, but it appears to me that
> both nameclt and the python script should attempt to narrow the object
> returned by the initial resolve_initial_references("NameService")
> call.

There is a minor difference between how omniORB C++ and omniORBpy deal
with narrowing. Both are correct within the CORBA specification, but
omniORBpy's behaviour provokes an Orbix bug.

I'm not sure exactly why from your traces, but omniORBpy decides that
it isn't sure about the type of the NamingContext reference, so on the
first call to the object, it uses _is_a() to check. omniORB C++
decides it _is_ sure about the type, so it just calls _non_existent()
to make sure the object exists. Both involve an extra round-trip to
the server, so there is no performance overhead in omniORBpy calling
_is_a(). Unfortunately, Orbix incorrectly returns false to the _is_a()
call, so omniORBpy complains.

If you hadn't said that you are using the latest CVS versions of
everything, I'd say that omniORBpy's behaviour was due to bug 3 in
omniORBpy 1.2:

  http://www.uk.research.att.com/omniORB/omniORBpy/bugfixes.html#bug3

If you are using the latest CVS version, there must be some other
reason for omniORBpy to think the object's type is not verified. It
might be because of the location forwarding which is going on.

Anyway, you can probably avoid the problem by specifying a command
line of -ORBverifyObjectExistsAndType 0. That prevents the _is_a()
call.


On to your other problem with nameclt list:

> omniORB: throw MARSHAL from exception.cc:422

That shows that Orbix marshalled something which omniORB thought was
invalid. Unfortunately, our cunning exception tracing code isn't quite
cunning enough, and doesn't tell us anything useful about what was
being unmarshalled when the exception occurred. One way to find out
where the error occurred is to modify
src/lib/omniORB2/orbcore/exception.cc around line 422, to be

void
_CORBA_marshal_error()
{
  abort();
  //  OMNIORB_THROW(MARSHAL,0,CORBA::COMPLETED_NO);
}

Then you can run nameclt in a debugger (having built the ORB core with
debugging info), and see where the call to _CORBA_marshal_error was
made from.

Cheers,

Duncan.

-- 
 -- Duncan Grisby  \  Research Engineer  --
  -- AT&T Laboratories Cambridge          --
   -- http://www.uk.research.att.com/~dpg1 --