Re: Interoperability of Orbit2

[Munaut Sylvain <tnt 246tNt com>]

Michael Meeks wrote:

>Hi Munaut,
>
>On Mon, 2003-03-10 at 17:13, Munaut Sylvain wrote:
>  
>
>>Yeah still some problems. But here, setVu seem to work and not replaceVu 
>>    
>>
>
>	Right; I've just read the code and I think I have a handle on the
>problem.
>  
>
That would be great ;)

>>I added ..
>>    
>>
>
>	That's great: most helpful, thanks.
>
>Incoming IIOP body:
>0x0000:   00 94 b4 b0  03 00 00 00  00 00 00 00  00 00 00 1c | ................ --- 
>0x0010:   00 00 00 00  d2 d9 48 96  34 8b 6e 38  12 8b 10 02 | ......H.4.n8....
>0x0020:   85 3b 1f ea  01 00 00 00  97 54 d0 d8  00 00 00 0a | .;.......T......
>0x0030:   72 65 70 6c  61 63 65 56  75 00 00 00  00 00 00 00 | replaceVu.......
>0x0040:   20 XX XX XX  XX XX XX XX  XX XX XX XX  XX XX XX XX | .***************
>p20747 : ([0x8050c10])->replaceVu (recv_buffer->end - recv_buffer->cur : -3
>
>	Ok - I think in GIOP 1.2, there is a ServiceContextList sequence which
>is empty with your ORB after the 'opName; somehow this is not advancing
>some pointer in ORBit2 - quite possibly in our generic sequence
>demarshaller - and then we are supposed to do an alignment to an 8 byte
>boundary. The most amazing thing is that aligns the pointer to offset
>0x0044 (by my arithmetic) - which is very wrong, it should be 0x0040 the
>beginning of '20 xx xx xx'.
>
>	Is it possible that you've hacked the alignment check in
>giop-recv-buffer.c (alloc_buffer) ? 
>
No ... The code come directly from CVS. Same problem with the latest 
stable release ...

>also can you add a:
>
>	fprintf (stderr, "end header demarshal %p %p\n", 
>			  buf->message_body, buf->end);
>
>	right before the return in giop_recv_buffer_demarshal_request_1_2 ?
>then we can really get to grips with this.
>
>  
>
The new log is at :
http://www.246tNt.com/vu_demarshal.log

Same sequence as usual ...

Thanks for your help
    Sylvain Munaut