[omniORB] SIGSEGV in marshalPyObjectWChar

[Joel Wagner]

I've analyzed this enough on the TAO side to be convinced that TAO is the
first place to look.  At about the point where the odd pattern creeps in to
the message TAO debug output is complaining that it is having problems
assembling messages.

Here are the messages from TAO just in case someone searches email archives
for this problem:

	TAO (23857|1024) Queued_Data::make_uncompleted_message: made
uncompleted message from 1024 bytes into qd=80b5730
:state=WAITING_TO_COMPLETE_PAYLOAD,missing_data_bytes=188
	(23857|1024) Transport[9]::handle_input_i: still have an uncompleted
message; will try 1 more times before letting somebody else have a chance.
	(23857|1024) Transport[9]::handle_input_i: trying to use 0 (of 0)
bytes to complete message missing 188 bytes
	TAO (23857|1024) - Transport[9]::handle_input_i, read 188 bytes on
attempt
	(23857|1024) Transport[9]::handle_input_i: completed and queued
message for processing!


I've posted these findings to the group we get TAO support from.

Thanks for your help,

Joel

-----Original Message-----
From: Duncan Grisby [mailto:duncan at grisby.org] 
Sent: Tuesday, April 20, 2004 12:06 PM
To: Joel Wagner
Cc: 'omniorb-list at omniorb-support.com'
Subject: Re: [omniORB] SIGSEGV in marshalPyObjectWChar 

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