Re: Interoperability of Orbit2

[Michael Meeks <michael ximian com>]

Hi Munaut,

	I have an idea :-) it suddenly strikes me that this may be related to
method name lengths; it seems all your method names are a multiple of 4
characters. It's possible that this has an impact on how we're doing
string alignment ( since in fact we need to transmit the extra '\0' on
the end ).

	Do you get the same problems if you rename s/Value/Vu/ everywhere ?
still, since the wire data looks just fine, and you're not getting '0's
but strange random numbers back, perhaps it's unlikely.

On Fri, 2003-03-07 at 16:36, Munaut Sylvain wrote:
> It's a PPC machine (OSX). The only difference with setValue and 
> replaceValue is that one return a value, the other don't.

	Sure; and replaceValue works fine ... so that's prolly not it.

p15861 : ([0x8050c78])->setValue (0xe0)[080508A0] setValue called : 224 

	This line is printed out from: orbit-small.c:741 or so
(tprintf_trace_value). If it's wrong by there - it's never going to be
right when it's pulled out.

	So I think if you can get a breakpoint into the method just before we
do the do_demarshal_value, and print out the 'buf->end - buf->cur', that
would be most interesting. It's possible we're overrunning the buffer
somehow - which would be most concerning.

	If you could send that, with the ORBIT2_DEBUG=giop:traces trace
intertwined - it'd be most interest.

	Many thanks,

		Michael.

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