[omniORB] MARSHAL Exception with Visibroker/Java and Any

[David Riddoch]

Gary,


Although in my last message I claimed responsibility for this problem, now
I'm not so sure. We do fail in the case of indirections to fundamental
types (which although strictly legal would be an odd thing to do, as it
would increase the length of the TypeCode on the wire). However, I
beliebe we do handle strings correctly - so should have no problems with
this particular case.

The value which we are receiving is a TypeCode indirection. The 'offset'
value is supposed to be an offset to a previous TypeCode in the stream.
Because TypeCodes are always 4 byte aligned (including indirections and
encapsulations) I would expect the offset to be a multiple of 4 ... so I
don't understand why we get an offset of -25. Perhaps this is in fact a
bug in Visibroker/Java.


David


On Thu, 11 Mar 1999, Gary D. Duzan wrote:

> 
>    I'm seeing a problem when trying to have a Visibroker/Java process
> send an Any-encoded struct to an OmniORB process. Running it through
> the debugger I'm seeing that it is dying while trying to unmarshall the
> typecode. I believe I have all the appropriate patches applied. The
> CORBA::MARSHAL exception is being raised in
> 
> Typecode_marshaller::unmarshall(MemBufferedStream&,
> 				TypeCode_offsetTable*).
> 
> Some local variable values are tck=0xffffffff, currpos=96, and
> offset=-25. It was called by
> 
> TypeCode_struct::NP_unmarshallComplexParams(MemBufferedStream&,
> 					    TypeCode_offsetTable*).
> 
> The encoded type is a struct with 9 fields, and it seems to be choking
> on the 2nd one. The first two fields are both strings. The name and
> typecode for the first seem to be unmarshalled fine, getting a
> plt_Simple and CORBA::tk_string in the respective switch blocks, and
> while the name of the second is unmarshalled fine, the typecode comes
> out as plt_None and 0xffffffff.
>    Has anyone else seem anything like this? It could certainly be a
> Visibroker/Java problem, but with all the new Any code in 2.7.0, I tend
> to suspect OmniORB. We're trying 2.5.0 to see if we can get that to
> work, but we haven't finished recompiling yet. Any help getting this to
> work would be appreciated.
> 
> 					Gary Duzan
> 					GTE Laboratories
> 
> 
> 
>