Re: Using remote method-calls over a tcp/ip network

[Philip Van Hoof <spamfrommailing freax org>]

On Fri, 2004-09-17 at 16:59 +0800, Kuang-Chun Cheng wrote:
> Hi,
> 
> I decode your IOR string and get following:
> 
> -----------------------------------------------------------------------------------------------------------
> Object ID: IDL:EzxS/Srvr:1.0
> IOP_TAG_ORBIT_SPECIFIC: usock 
> /tmp/orbit-pvanhoof/orb-2036448948343356007 IPv6 port 0
>     object_key (24) '000000001013b87e5139df3e01000000ff2d996cf666a434'
> 
> IOP_TAG_INTERNET_IOP: GIOP 1.0 linux-2.maia-scientific.com:38663
>     object_key (24) '000000001013b87e5139df3e01000000ff2d996cf666a434'
> -----------------------------------------------------------------------------------------------------------


> Maybe you should try to add
> 
> 192.168.0.23 linux-2.maia-scientific.com  linux-2

> to /etc/hosts at your client.

I altered my hosts-file like that. Everything remains the same as
before :-\

> 
> And if it's a network setup problem, you should get COMM_FAILURE
> at the time you call CORBA_ORB_string_to_object().

I am not getting the problem at the CORBA_ORB_string_to_object() call. I
am getting it at just one specific remote-method call. 

When debugging the ORBit-1 server, we can see it reach the the very last
call in the function (which is, of course, the return). The object that
we are going to be returning is 100% correct. Every piece of information
that we can possible get out of a running debugging session (we are
using ddd and gdb for this) looks 100% correct.

Then it returns . . .

And then the client also returns. But the "ev" parameter (the CORBA
environment variable) has COMM_Failure exception and the object that has
been returned at the client does not look like what we returned at the
server at all. We think that it's just a g_malloc (not a g_malloc0)
since the values inside the struct are pure random.

When we do this on the same machine. So there is no tcp/ip involved here
(or using a UNIX socket, I don't know), everything works perfectly.

> At which point you got COMM_FAILURE ?

After one specific remote method returned. Note that we do have very
similar other such methods which also return sequences. They even do
pretty much the same thing. Those methods do work.

> ORBit2 speak GIOP 1.2 instead of GIOP 1.0.   I don't konw if this might
> be the problem ... don't have much experience about ORBit,  can't help
> on that.

To get rid of the problem we are already planning to start the huge work
of porting our ORBit-1 server to ORBit-2. Luckily the GLib-2 library
looks very backwards compatible with the GLib-1. We already have the
thing compiling actually ;-). But there are some other issues with
binary modules of some of or vendors. Also, this is a piece of software
with more than 15 manyears of work behind. It's not "simple" to port
code which was created while I was still a child. Hehe . . . 


Nevertheless, it should work on ORBit-1, no?

However. We can fix this specific problem just by creating a new method
that packs the information in for example XML after UUEncoding it, or
whatever. But we can't fix the array-problem (which is the other
problem) :-). We are using arrays all over the place . . . 

And it's not just one remote method that is failing. It's also failing
when we are using both server and client on the same machine.

It's the very simple struct:


 long x;
 long y;
 long list1[6]; 
 long list1[6]; 
 long list1[6]; 
 long z;


If we transfer it from server to client, z is not correct. if we
transfer it from client to server, server crashes at some obscure
location (actually gdb sais it's crashing in eval.c at line 41. Note
that we don't have a file eval.c nor a line 41) (server is ORBit-1,
client is ORBit-2).

If we put the arrays as the last elements in the struct (hehe, we tried
to be smarted than the bug), the next object in the argument list of the
function becomes corrupted. Stack corrupted?

But again, we are planning to create a Hello-World type of application
sooner or later and see whether or not we can reproduce the problem.



-- 
Philip Van Hoof, Software Developer @ Cronos
home: me at freax dot org
gnome: pvanhoof at gnome dot org
work: philip dot vanhoof at cronos dot be
junk: philip dot vanhoof at gmail dot com
http://www.freax.be, http://www.freax.eu.org