[omniORB] MARSHAL Exception with Visibroker/Java and Any

Gary D. Duzan gdd0@gte.com
Fri, 12 Mar 1999 17:19:09 -0500


   Yes, it is now looking like this is an off-by-one Visibroker bug. I
added this to the beginning of lookupOffset() in typecode.cc as a quick
hack to get it to work:

  offset = ((offset+3) & 0xfffffffc);

Assuming that proper offsets are always aligned, this shouldn't break
any properly functioning typecodes. We'll be reporting this to
Inprise so we can get a real fix (eventually, maybe).

					Gary Duzan
					GTE Laboratories



In Message <Pine.LNX.4.04.9903121435000.19547-100000@pitanga> ,
   David Riddoch <djr@uk.research.att.com> wrote:

=>
=>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
=>> 
=>> 
=>> 
=>> 
=>
=>
=>