Re: Interoperability of Orbit2

[Michael Meeks <michael ximian com>]

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.

> 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) ? 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.

	Many thanks,

		Michael.


-- 
 mmeeks@gnu.org  <><, Pseudo Engineer, itinerant idiot