[omniORB] Problem with system() call on HPUX 10.20

[Sai-Lai Lo]

It looks to me this is a HPUX 10.20 thread library problem.
I'm not sure it is omniORB specific or related to the way omniORB is built.

Have you verified that doing a system() call from a thread which is not the
main() thread actually works? It won't be hard to just write a small test
program in C using pthread and try system() in a thread spawn by the main
thread. 

HPUX 10.x pthread is a user space only library. In other words, it is a
single threaded process pretends to be multi-threaded by wrap around blocking
system calls such as send(), recv() with its own glue. 

I guess you may have a better chance of getting system() to work if it is
called from the main thread but this is pure speculation. If that works
then as a work around you'll have to do some thread synchronisation to get
the main thread to do the actual system() call.

For what is worth, your example works fine on HPUX 11.00. As I don't have
access to an HPUX 10.x machine, I'm afraid you have to do a lot more
debugging yourself.

Sai-Lai



>>>>> Xuekai Song writes:

> I posted the following problem two weeks ago and have not
> got any comments/feedbacks so far.  Here it is again hoping
> somebody out there may have an answer or some ideas.
> ---

> In my omniORB server (omniORB 2.8, HPUX 10.20), I need
> to invoke an external application by using system().  The
> system() works ok the first time.  But it somehow failed when
> called the second time, i.e. the server stopped responding after:

> tcpSocketMTfactory Rendezvouser: unblock from accept()
> tcpSocketMTfactory Rendezvouser: accept new strand.
> tcpSocketMTfactory Rendezvouser: block on accept()

> To narrow down the cause, I tried the system() call in the
> echo example3 of omniORB2_8_0.  There are only two changes
> that I made to "echo_i.cc":

> 1) #include <stdlib.h> /*** added for testing ***/
> 2) char *p = CORBA::string_dup(mesg);
>    system("date"); /*** added for testing ***/
>    return p;

> Here system("date") is used to simplify the problem.
> To produce the problem, I started eg3_impl on one console.
> Then eg3_clt is started on another console for the first time
> and it worked ok by returning:

> I said,"Hello!". The Object said,"Hello!"

> And on the server console it displays:

> Wed Aug  2 11:19:08 WETDST 2000

> However, when eg3_clt is invokded again, it failed after
> ll_send.  Below is the trace info from the client window by
> using -ORBtraceLevel 30:

> ll_send: 119 bytes
> 4749 4f50 0100 0000 0000 006b 0000 0000 GIOP.......k....
> 0000 0002 0187 e28a 0000 000c 3987 e28a ............9...
> c67d 879d 0000 0002 0000 0008 7265 736f .}..........reso
> 6c76 6500 0000 0007 6e6f 626f 6479 0000 lve.....nobody..
> 0000 0002 0000 0005 7465 7374 0000 0000 ........test....
> 0000 000b 6d79 5f63 6f6e 7465 7874 0000 ....my_context..
> 0000 0005 4563 686f 0000 0000 0000 0007 ....Echo........
> 4f62 6a65 6374 00                       Object.
> ll_recv: 100 bytes
> 4749 4f50 0100 0001 0000 0058 0000 0000 GIOP.......X....
> 0000 0002 0000 0000 0000 000d 4944 4c3a ............IDL:
> 4563 686f 3a31 2e30 0000 0000 0000 0001 Echo:1.0........
> 0000 0000 0000 002c 0001 0000 0000 000f .......,........
> 3133 322e 3235 332e 3131 322e 3934 0000 132.253.112.94..
> 0fbe 0000 0000 000c 3987 f57f cdce a877 ........9......w
> 0000 0002                               ....
> omniORB: strand Rope::incrRefCount: old value = 0
> ll_send: 32 bytes
> 4749 4f50 0100 0003 0000 0014 0000 0001 GIOP............
> 0000 000c 3987 f57f cdce a877 0000 0002 ....9......w....
> omniORB: scavenger : start.
> omniORB: strand Ripper: start.
> omniORB: scavenger : scanning connections
> omniORB: scavenger : scanning connections

> I also tested this on NT 4.0 and it worked without the problem.
> Could it be because omniORB was not built properly on my HPUX
> 10.20 (built using aCC: HP ANSI C++ B3910B A.01.15) or could
> it be something else in omniORB?

> Thanks in advance for any feedback.

> Xuekai Song







-- 
Sai-Lai Lo                                   S.Lo@uk.research.att.com
AT&T Laboratories Cambridge           WWW:   http://www.uk.research.att.com 
24a Trumpington Street                Tel:   +44 1223 343000
Cambridge CB2 1QA                     Fax:   +44 1223 313542
ENGLAND