[omniORB] SIGSEGV in marshalPyObjectWChar

[Duncan Grisby]

On Tuesday 20 April, Joel Wagner wrote:

> Tried changing the wchar array initialization from:
> 
> m.MediaLabel = u'x'  * 65
> m.MediaDescription = u'y'  * 257
> m.Barcode =  u'z'  * 33
>  
> To:
> 
> m.MediaLabel = [ u'x' ] * 65
> m.MediaDescription = [ u'y' ] * 257
> m.Barcode = [ u'z' ] * 33
> 
> omniORBpy stopped SIGSEGV'ing but looks like marshaling errors are occurring
> when talking to a TAO server from an omniORBpy client

As you have found, the correct representation for an array of wchars
in Python is a list of one character unicode strings, not one bit
unicode string. The segfault was an error in the type validation
code. I've fixed the code in CVS so now if you use unicode strings
when lists are required, you will get a BAD_PARAM exception as you
should.

[...]
> 0079 0200 7902 0079 0200 7902 0079 0200 .y..y..y..y..y..
> 7902 0079 0200 cdcd 0079 0200 7902 0079 y..y.....y..y..y
> 0200 7902 0079 0200 7902 0079 0200 7902 ..y..y..y..y..y.
> 0079 0200 7902 0079                     .y..y..y
> omniORB: throw MARSHAL from cs-UTF-16.cc:347 (YES,MARSHAL_InvalidWCharSize)

This looks like a bug in TAO's marshalling code to me. wchars are
marshalled in a strange way, as one octet indicating the size in
octets of the wchar, followed by that number of octets for the
character. In the above trace, you can see each wchar is marshalled as
020079, i.e. length 2 followed by that char code 0079 (in big endian
since that's the default for UTF-16).

All of the wchars sent by omniORB look like that; most of the ones in
TAO's reply do too, but look at the second line I've quoted above. It
goes 79 (left from the whcar that started on the previous line)
020079, which is fine, 0200cd, which is a valid encoding, but probably
not the character you meant, then cd0079..., which claims to be a
wchar encoded as 205 octets. omniORB complains about that, as it
should.

I think you should get the TAO people to look at this. I suppose
there's small possibility that omniORB is somehow corrupting the data
TAO is sending, but I don't think that's likely. Does TAO have an
equivalent to omniORB's traceLevel 40 that prints GIOP traces?  If so,
you can confirm that TAO really is sending what omniORB thinks it has
received.

Cheers,

Duncan.

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