[omniORB] interoperability : omniORBpy 3.2 and Visibroker 8.0 - omniORB.MARSHAL_InvalidIndirection error

Duncan Grisby duncan at grisby.org
Mon May 17 19:31:15 BST 2010


On Thu, 2010-03-25 at 16:45 +0200, eLAN wrote:

> The attached log contains the logging with the patch.

My apologies for the very long delay in replying to this. Diagnosing it
involves unpicking the GIOP data in the log, and that's a painful and
time consuming activity that I've only just had time for.

My conclusion is that it is a bug in Visibroker. The server is sending a
sequence of TupleItem structs, each of which contains an Any. The first
Any contains an OID struct, and the TypeCode and value are sent
correctly. The next sequence item contains an ObjectNumberForAny struct,
and again the TypeCode and value are correctly transmitted. The next
item is clearly also meant to contain an ObjectNumberForAny struct, but
Visibroker does not send a full TypeCode for it. Instead, it sends an
indirection pointing to the already-sent ObjectNumberForAny TypeCode.
Indirections are a negative number giving an offset to a previously-sent
TypeCode.

Unfortunately, it is not permitted to do that in this situation!  The
CORBA 2.6 specification, section 15.3.5.1 says:

        ... CDR provides a constrained indirection to resolve this
        problem:
        
        * The indirection applies only to TypeCodes nested within some
        'top-level' TypeCode. Indirected TypeCodes are not
        'freestanding', but only exist inside some other encoded
        TypeCode.

Although the indirection TypeCodes that Visibroker is sending are all in
the same response, they are not all nested within a top-level TypeCode,
and they are therefore illegal. omniORB is right to throw a MARSHAL
exception.

I'm not sure what to suggest, other than to report it as a bug in
Visibroker.

Cheers,

Duncan.

-- 
 -- Duncan Grisby         --
  -- duncan at grisby.org     --
   -- http://www.grisby.org --





More information about the omniORB-list mailing list