Re: client locks up somewhere in giop

[Diego Sevilla Ruiz <dsevilla ditec um es>]

Hi, Ross:

    This seems to be the classical "deadlock" problem within client and
server. At least at first sight.

    When your client calls a server, this petition must end *before* the
client can receive any petition back from the server. In other words: the
interaction must always follow the pattern:

client invokes server -> server retunrs results -> client invokes server ->
server returns results.

I think your pattern is:

client invokes server -> server does something and tries to invoke client
again (deadlock, as client is waiting for the first call to return.  Server
cannot invoke any operation in the client).

    Could this be your problem?

    Best regards and hope this helps.
    diego.

Ross Golder wrote:

> I have written the beginnings of a bot program, using ORBit for
> inter-process communication between the main bot and a dynamic array of
> out-of-process modules that implement the different types of
> functionality. It is an excercies in using CORBA more than anything.
>
> However, I am unable to determine why, after a few successfull
> interactions between the two processes, the caller goes into a
> CPU-caning loop waiting for the called object to return from a call.
>
> I'm using RH71/ORBit-0.5.8-ximian.2.
>
> When I break out of the looping process run in gdb, the stacktrace
> shows:
>
> Program received signal SIGINT, Interrupt.
> [Switching to Thread 1026 (LWP 16321)]
> 0x4024790e in __select () from /lib/i686/libc.so.6
> (gdb) bt
> #0  0x4024790e in __select () from /lib/i686/libc.so.6
> #1  0x4012615c in __DTOR_END__ () from /usr/lib/libIIOP.so.0
> #2  0x4011ebb2 in giop_main_next_message_2 (blocking=1,
> monitor=0x805a440)
>     at connection.c:1174
> #3  0x4012004c in giop_recv_reply_buffer_use_multiple_2
> (request_cnx=0x805a440,
>     request_ids=0x40abe544, block_for_reply=1) at giop-msg-buffer.c:1013
> #4  0x4012015b in giop_recv_reply_buffer_use_2 (request_cnx=0x805a440,
>     request_id=1085007260, block_for_reply=1) at giop-msg-buffer.c:1062
> #5  0x0804bdc1 in Techbot_Module_processMessage (_obj=0x805a3b0,
> message=0x40abe61c,
>     ev=0x40abe60c) at techbot-stubs.c:2104
> #6  0x0804da08 in libirc_callback (message=0x805a7d0) at
> techbot-modulehub-impl.c:528
> #7  0x0804e1a6 in irc_connection_handle_message (conn=0x8056690,
> message=0x805a7d0)
>     at irc_connection.c:263
> #8  0x0804df47 in irc_thread_connect (ptr=0x8056690) at
> irc_connection.c:163
> #9  0x40158bfd in pthread_start_thread (arg=0x40abec00) at manager.c:262
> #10 0x40158cdf in pthread_start_thread_event (arg=0x40abec00) at
> manager.c:285
>
> As I 'continue', it seems to loop through :
>
> ORBit_handle_incoming_message (recv_buffer=0x8055338) at server.c:153
> giop_received_list_push (recv_buffer=0x8055338) at giop-msg-buffer.c:928
> g_list_prepend (list=0x0, data=0x8055338) at glist.c:198
> g_list_prepend (list=0x0, data=0x8055338) at glist.c:201
> giop_received_list_push (recv_buffer=0x8055338) at giop-msg-buffer.c:930
> ORBit_handle_incoming_message (recv_buffer=0x8055338) at server.c:174
> giop_main_iterate (blocking=1) at connection.c:1285
> giop_main () at connection.c:1149
> giop_main_iterate (blocking=1) at connection.c:1277
> giop_main_next_message (blocking=1) at connection.c:1159
> giop_main_next_message_2 (blocking=1, monitor=0x0) at connection.c:1170
> giop_received_list_pop () at giop-msg-buffer.c:939
> g_list_remove_link (list=0x805248c, link=0x805248c) at glist.c:300
> giop_received_list_pop () at giop-msg-buffer.c:946
> g_list_free_1 (list=0x805248c) at glist.c:159
> giop_received_list_pop () at giop-msg-buffer.c:950
> giop_main_next_message_2 (blocking=1, monitor=0x0) at connection.c:1171
> giop_main_next_message (blocking=1) at connection.c:1160
> giop_main_iterate (blocking=1) at connection.c:1279
> ...and back to...
> ORBit_handle_incoming_message (recv_buffer=0x8055338) at server.c:153
>
> The called method seems to execute correctly, and this appears to be
> happening on returning from the call. I can't imagine what would cause
> it
>
> I'm not sure what other information is required to analyse this problem
> further. If anyone can suggest any further actions or investigations I
> can make, I'd appreciate it.
>
> If anyone wants to see the code, it is fairly trivial, and is checked
> into cvs.techbot.sourceforge.net, module 'techbot', branch
> 'libirc-breakdown'.
>
> Thanks in advance for any advice,
>
> --
> Ross
>
> _______________________________________________
> orbit-list mailing list
> orbit-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/orbit-list

--
Diego Sevilla Ruiz -- http://ditec.um.es/~dsevilla/ -- dsevilla@um.es
Dep. Ingeniería y Tecnología de Computadores, Facultad de Informática
Univ.de Murcia,Campus Espinardo,30080 Murcia (SPAIN),Tel.+34968367658
lynx -dump ditec.um.es/~dsevilla/face |uncompface | ikon2xbm |display
PGP:  http://pgp.rediris.es:11371/pks/lookup?op=get&search=0xC9B964B7
perl -e'$_="\x4\@FLe\x2&B";for(/../g){print unpack("b*",$_),"\n"}'|tr 01 " #"
(lambda x,f=lambda x,f:x and x[-1]+f(x[:-1],f):f(x,f))('se.mu@allivesd')