Re: client locks up somewhere in giop

[Ross Golder <ross golder org>]

On Wed, 2001-10-10 at 17:14, Diego Sevilla Ruiz wrote:
> 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?
> 

At present, the function on the server I am calling is a simply
g_warning, and immediate return. It is not calling back to the client
(although I originally believed that was possible before you explained
it).

However, it could be that two threads are making client->server calls
simultaneously. Should I have to synchronise these calls somehow?

--
Ross

>     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')
> 
> 
> 
> 
> _______________________________________________
> orbit-list mailing list
> orbit-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/orbit-list