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

Xuekai Song kai@ptc.com
Wed, 02 Aug 2000 06:34:59 -0400


--------------60A6B7582B4F7CB89844F373
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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


--------------60A6B7582B4F7CB89844F373
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
In my omniORB server (omniORB 2.8, HPUX 10.20), I need
<br>to invoke an external application by using system().&nbsp; The
<br>system() works ok the first time.&nbsp; But it somehow failed when
<br>called the second time, i.e. the server stopped responding after:
<p><tt>tcpSocketMTfactory Rendezvouser: unblock from accept()</tt>
<br><tt>tcpSocketMTfactory Rendezvouser: accept new strand.</tt>
<br><tt>tcpSocketMTfactory Rendezvouser: block on accept()</tt>
<p>To narrow down the cause, I tried the system() call in the
<br>echo example3 of omniORB2_8_0.&nbsp; There are only two changes
<br>that I made to "echo_i.cc":
<p><tt>1) #include &lt;stdlib.h> /***&nbsp;added for testing ***/</tt>
<br><tt>2) char *p = CORBA::string_dup(mesg);</tt>
<br><tt>&nbsp;&nbsp; system("date"); /***&nbsp;added for testing ***/</tt>
<br><tt>&nbsp;&nbsp; return p;</tt>
<p>Here system("date") is used to simplify the problem.
<br>To produce the problem, I started eg3_impl on one console.
<br>Then eg3_clt is started on another console for the first time
<br>and it worked ok by returning:
<p><i><tt>I said,"Hello!". The Object said,"Hello!"</tt></i><tt></tt>
<p>And on the server console it displays:<tt></tt>
<p><i>Wed Aug&nbsp; 2 11:19:08 WETDST 2000</i>
<p>However, when eg3_clt is invokded again, it failed after
<br>ll_send.&nbsp; Below is the trace info from the client window by
<br>using -ORBtraceLevel 30:
<p><tt>ll_send: 119 bytes</tt>
<br><tt>4749 4f50 0100 0000 0000 006b 0000 0000 GIOP.......k....</tt>
<br><tt>0000 0002 0187 e28a 0000 000c 3987 e28a ............9...</tt>
<br><tt>c67d 879d 0000 0002 0000 0008 7265 736f .}..........reso</tt>
<br><tt>6c76 6500 0000 0007 6e6f 626f 6479 0000 lve.....nobody..</tt>
<br><tt>0000 0002 0000 0005 7465 7374 0000 0000 ........test....</tt>
<br><tt>0000 000b 6d79 5f63 6f6e 7465 7874 0000 ....my_context..</tt>
<br><tt>0000 0005 4563 686f 0000 0000 0000 0007 ....Echo........</tt>
<br><tt>4f62 6a65 6374 00&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Object.</tt>
<br><tt>ll_recv: 100 bytes</tt>
<br><tt>4749 4f50 0100 0001 0000 0058 0000 0000 GIOP.......X....</tt>
<br><tt>0000 0002 0000 0000 0000 000d 4944 4c3a ............IDL:</tt>
<br><tt>4563 686f 3a31 2e30 0000 0000 0000 0001 Echo:1.0........</tt>
<br><tt>0000 0000 0000 002c 0001 0000 0000 000f .......,........</tt>
<br><tt>3133 322e 3235 332e 3131 322e 3934 0000 132.253.112.94..</tt>
<br><tt>0fbe 0000 0000 000c 3987 f57f cdce a877 ........9......w</tt>
<br><tt>0000 0002&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
....</tt>
<br><tt>omniORB: strand Rope::incrRefCount: old value = 0</tt>
<br><tt>ll_send: 32 bytes</tt>
<br><tt>4749 4f50 0100 0003 0000 0014 0000 0001 GIOP............</tt>
<br><tt>0000 000c 3987 f57f cdce a877 0000 0002 ....9......w....</tt>
<br><tt>omniORB: scavenger : start.</tt>
<br><tt>omniORB: strand Ripper: start.</tt>
<br><tt>omniORB: scavenger : scanning connections</tt>
<br><tt>omniORB: scavenger : scanning connections</tt>
<p>I also tested this on NT 4.0 and it worked without the problem.
<br>Could it be because omniORB was not built properly on my HPUX
<br>10.20 (built using aCC: HP ANSI C++ B3910B A.01.15) or could
<br>it be something else in omniORB?
<p>Thanks in advance for any feedback.
<p>Xuekai Song
<br>&nbsp;</html>

--------------60A6B7582B4F7CB89844F373--