[omniORB] Debugging marshaling errors

Jason Stelzer jstelzer at healthmarketscience.com
Tue Jul 31 17:19:10 BST 2007


On Jul 31, 2007, at 11:23 AM, Jason Stelzer wrote:

>
> Thanks. I just misunderstood the example in Pure Corba. At this  
> point it looks as if the right callbacks are firing. The factory  
> seems to be doing the right thing, sort of.
>
> I see
>
> omniORB: (0) Unmarshal value  
> 'RMI:com.hmsonline.lms.common.AddressResults: 
> 43D80F328F139FE0:00000000013240E2'.
> omniORB: (0) Unmarshal value 'IDL:omg.org/CORBA/WStringValue:1.0'.
> omniORB: (0) Unmarshal value 'IDL:omg.org/CORBA/WStringValue:1.0'.
> omniORB: (0) Received UTF-16 string with no byte order mark.
> omniORB: (0) Unmarshal value 'IDL:omg.org/CORBA/WStringValue:1.0'.
> ...
>
> Howerver, when I try and access the data that should have been  
> marshaled it seems to be null. Further, when I look at the returned  
> pointer, I see
> (gdb) print *output
> $5 = {
>   <CORBA::ValueBase> = {
>     _vptr.ValueBase = 0x59c744,
>     static _PD_repoId = 0x4e7524 "IDL:omg.org/CORBA/ValueBase:1.0",
>     static _PR_magic = 1447119938,
>     _pd_magic = 1447119938
>   },
>   members of com::hmsonline::lms::common::AddressResults:
>   _vptr.AddressResults = 0x59c5a8,
>   static _PD_repoId = 0x5970d4  
> "RMI:com.hmsonline.lms.common.AddressResults: 
> 43D80F328F139FE0:00000000013240E2"
> }
>
>
> My understanding of the way this is supposed to work is this:
> 1. remote method is called which returns a pass by value object
> 2. The local orb reads the rep ID and looks up the factory in its  
> factory table.
> 3. The orb calls create_for_unmarshal on the factory (which returns  
> the Impl class).
> 4. The orb is then responsible for initializing the new object  
> returned by the factory.
> 5. The returned object is the unmarshaled value object.
>
> I would have expected to see quite a bit more data in the returned  
> structure.
>

Just a follow up on how I resolved this.

After exploring memory addresses and dumping objects, I'm reasonably  
sure that my idl is simply subtly busted or overly complicated.

What I did find that worked quite well was to use a java object with  
public member varialbles as a glorified struct for return values.  
Yes, it breaks encapsulation, but it has something the object with  
accessor methods lacked. Namely it operates correctly. So, I just  
regenerated the idl from the class and access string data from  
results.member directly.

Thanks for all the help :)

--
J.





More information about the omniORB-list mailing list