[omniORB] Problem with system() call on HPUX 10.20
Xuekai Song
kai@ptc.com
Tue, 15 Aug 2000 13:48:11 -0400
--------------CC8EABB6CF6CAB899E6CAE8C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sai-Lai,
Thanks for the suggestion. I tried system() call in a simple C++ program as
shown below:
#include <stdlib.h>
#include <iostream.h>
#include <pthread.h>
/*
aCC -DHP_THREAD_SAFE -D_HPUX_SOURCE -DPthreadDraftVersion=4 -D_REENTRANT
+DAportable -o test test.cpp -lstd -lcma
*/
void foo()
{
for (int i=0; i<2; i++)
system("date");
}
int main()
{
pthread_t tid;
pthread_attr_t attr;
pthread_attr_create(&attr);
try {
for (int i=0; i<5; i++)
{
int ret = pthread_create(&tid, attr, (void*(*)(void*))foo, 0);
cout << "ret = " << ret << endl;
sleep(1);
}
}
catch(int n) {
cout << "caught " << n << endl;
}
return 1;
}
It works without problems. So it looks that the problem is somehow related
to omniORB, but I don't know how. As for building omniORB 2.8, I used similar
aCC options as shown above which is suggested by HP.
Also in my omniORB server code, the system() call is invoked from the main
thread while a seprate omni thread was created before that to initialize CORBA.
And the problem remains the same if I do it the other way around.
But it's good to know that the problem does not exist on HPUX 11.00 and this
will certainly be a workaround (although not ideal).
Xuekai Song
---
Sai-Lai Lo wrote:
> 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
--------------CC8EABB6CF6CAB899E6CAE8C
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Sai-Lai,
<p>Thanks for the suggestion. I tried system() call in a simple C++
program as
<br>shown below:
<p><tt><font size=-1>#include <stdlib.h></font></tt>
<br><tt><font size=-1>#include <iostream.h></font></tt>
<br><tt><font size=-1>#include <pthread.h></font></tt><tt><font size=-1></font></tt>
<p><tt><font size=-1>/*</font></tt>
<br><tt><font size=-1>aCC -DHP_THREAD_SAFE -D_HPUX_SOURCE -DPthreadDraftVersion=4
-D_REENTRANT +DAportable -o test test.cpp -lstd -lcma</font></tt>
<br><tt><font size=-1>*/</font></tt><tt><font size=-1></font></tt>
<p><tt><font size=-1>void foo()</font></tt>
<br><tt><font size=-1>{</font></tt>
<br><tt><font size=-1> for (int i=0; i<2; i++)</font></tt>
<blockquote><tt><font size=-1> system("date");</font></tt></blockquote>
<tt><font size=-1>}</font></tt><tt><font size=-1></font></tt>
<p><tt><font size=-1>int main()</font></tt>
<br><tt><font size=-1>{</font></tt>
<br><tt><font size=-1> pthread_t tid;</font></tt>
<br><tt><font size=-1> pthread_attr_t attr;</font></tt>
<br><tt><font size=-1> </font></tt>
<br><tt><font size=-1> pthread_attr_create(&attr);</font></tt>
<br><tt><font size=-1> try {</font></tt>
<blockquote><tt><font size=-1> for (int i=0; i<5; i++)</font></tt>
<br><tt><font size=-1> {</font></tt>
<br><tt><font size=-1> int ret = pthread_create(&tid,
attr, (void*(*)(void*))foo, 0);</font></tt>
<br><tt><font size=-1> cout << "ret = " <<
ret << endl;</font></tt>
<br><tt><font size=-1> sleep(1);</font></tt>
<br><tt><font size=-1> }</font></tt></blockquote>
<tt><font size=-1> }</font></tt>
<br><tt><font size=-1> catch(int n) {</font></tt>
<blockquote><tt><font size=-1> cout << "caught " << n
<< endl;</font></tt></blockquote>
<tt><font size=-1> }</font></tt><tt><font size=-1></font></tt>
<p><tt><font size=-1> return 1;</font></tt>
<br><tt><font size=-1>}</font></tt><tt></tt>
<p>It works without problems. So it looks that the problem is somehow
related
<br>to omniORB, but I don't know how. As for building omniORB 2.8,
I used similar
<br>aCC options as shown above which is suggested by HP.
<p>Also in my omniORB server code, the system() call is invoked from
the main
<br>thread while a seprate omni thread was created before that to initialize
CORBA.
<br>And the problem remains the same if I do it the other way around.
<p>But it's good to know that the problem does not exist on HPUX 11.00
and this
<br>will certainly be a workaround (although not ideal).
<p>Xuekai Song
<br>---
<p>Sai-Lai Lo wrote:
<blockquote TYPE=CITE>It looks to me this is a HPUX 10.20 thread library
problem.
<br>I'm not sure it is omniORB specific or related to the way omniORB is
built.
<p>Have you verified that doing a system() call from a thread which is
not the
<br>main() thread actually works? It won't be hard to just write a small
test
<br>program in C using pthread and try system() in a thread spawn by the
main
<br>thread.
<p>HPUX 10.x pthread is a user space only library. In other words, it is
a
<br>single threaded process pretends to be multi-threaded by wrap around
blocking
<br>system calls such as send(), recv() with its own glue.
<p>I guess you may have a better chance of getting system() to work if
it is
<br>called from the main thread but this is pure speculation. If that works
<br>then as a work around you'll have to do some thread synchronisation
to get
<br>the main thread to do the actual system() call.
<p>For what is worth, your example works fine on HPUX 11.00. As I don't
have
<br>access to an HPUX 10.x machine, I'm afraid you have to do a lot more
<br>debugging yourself.
<p>Sai-Lai
<p>>>>>> Xuekai Song writes:
<p>> I posted the following problem two weeks ago and have not
<br>> got any comments/feedbacks so far. Here it is again hoping
<br>> somebody out there may have an answer or some ideas.
<br>> ---
<p>> In my omniORB server (omniORB 2.8, HPUX 10.20), I need
<br>> to invoke an external application by using system(). The
<br>> system() works ok the first time. But it somehow failed when
<br>> called the second time, i.e. the server stopped responding after:
<p>> tcpSocketMTfactory Rendezvouser: unblock from accept()
<br>> tcpSocketMTfactory Rendezvouser: accept new strand.
<br>> tcpSocketMTfactory Rendezvouser: block on accept()
<p>> To narrow down the cause, I tried the system() call in the
<br>> echo example3 of omniORB2_8_0. There are only two changes
<br>> that I made to "echo_i.cc":
<p>> 1) #include <stdlib.h> /*** added for testing ***/
<br>> 2) char *p = CORBA::string_dup(mesg);
<br>> system("date"); /*** added for testing ***/
<br>> return p;
<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 said,"Hello!". The Object said,"Hello!"
<p>> And on the server console it displays:
<p>> Wed Aug 2 11:19:08 WETDST 2000
<p>> However, when eg3_clt is invokded again, it failed after
<br>> ll_send. Below is the trace info from the client window by
<br>> using -ORBtraceLevel 30:
<p>> ll_send: 119 bytes
<br>> 4749 4f50 0100 0000 0000 006b 0000 0000 GIOP.......k....
<br>> 0000 0002 0187 e28a 0000 000c 3987 e28a ............9...
<br>> c67d 879d 0000 0002 0000 0008 7265 736f .}..........reso
<br>> 6c76 6500 0000 0007 6e6f 626f 6479 0000 lve.....nobody..
<br>> 0000 0002 0000 0005 7465 7374 0000 0000 ........test....
<br>> 0000 000b 6d79 5f63 6f6e 7465 7874 0000 ....my_context..
<br>> 0000 0005 4563 686f 0000 0000 0000 0007 ....Echo........
<br>> 4f62 6a65 6374 00
Object.
<br>> ll_recv: 100 bytes
<br>> 4749 4f50 0100 0001 0000 0058 0000 0000 GIOP.......X....
<br>> 0000 0002 0000 0000 0000 000d 4944 4c3a ............IDL:
<br>> 4563 686f 3a31 2e30 0000 0000 0000 0001 Echo:1.0........
<br>> 0000 0000 0000 002c 0001 0000 0000 000f .......,........
<br>> 3133 322e 3235 332e 3131 322e 3934 0000 132.253.112.94..
<br>> 0fbe 0000 0000 000c 3987 f57f cdce a877 ........9......w
<br>> 0000 0002
....
<br>> omniORB: strand Rope::incrRefCount: old value = 0
<br>> ll_send: 32 bytes
<br>> 4749 4f50 0100 0003 0000 0014 0000 0001 GIOP............
<br>> 0000 000c 3987 f57f cdce a877 0000 0002 ....9......w....
<br>> omniORB: scavenger : start.
<br>> omniORB: strand Ripper: start.
<br>> omniORB: scavenger : scanning connections
<br>> omniORB: scavenger : scanning connections
<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
<p>--
<br>Sai-Lai Lo
S.Lo@uk.research.att.com
<br>AT&T Laboratories Cambridge
WWW: <a href="http://www.uk.research.att.com">http://www.uk.research.att.com</a>
<br>24a Trumpington Street
Tel: +44 1223 343000
<br>Cambridge CB2 1QA
Fax: +44 1223 313542
<br>ENGLAND</blockquote>
</html>
--------------CC8EABB6CF6CAB899E6CAE8C--