[omniORB] omniORB possibly looping

[Kelly Burkhart]

Ralf Walther writes:
 > 
 > Hi Kelly,
 > 
 > you're right, I actually run into the same problem on HPUX10.20.
 > Are you using the environment ORACLE_SID to specify the database?
 > Unfortunately the only thing to do is, AVOID A FORK/EXEC IN CORBA   
 > servers.
 > In your case, try to connect to the Oracle database via the listener   
 > process. This will
 > let the listener start your db client process.
Thank you this worked perfectly.  (why didn't I think of that ;-)

 > 
 > So what is the problem of a fork/exec? It's not garanteed, that a
process   
 > sets the
 > close-on-exec flag of its acquired file descriptors. This effects the   
 > state of the forked process, ...
 > you see, ... the ORACLE client process inherits all open descriptors,   
 > which confuse the CORBA
 > server. I recognized, that the server waits for a socket resource
 > in tcpSocketRendezvouser::run_undetached, but there were enough free   
 > sockets available.
 > 
 > On my search for solutions I've found similar problems described for   
 > orbix as well. In orbix it's
 > recommended to let the daemon start server and to avoid forks in server   
 > processes.
 > 

Judy had some interesting info in her message about signal handlers.
That may be more in line with what I'm seeing.

I originally thought that the process was looping in libtcpwrapGK, I
don't think that is the case now.  It appears to be suspended waiting
on a signal in libc.  Prior to that it seems to loop calling setenv() and
putenv() alternately around 65000 times.  I'm not particularly worried 
about this now since I can connect through the listener, but I do find 
it curious.

The stack trace looks like this (I added \ linebreak on some long lines):

(gdb) where
#0  0x40593bf4 in __syscall_sigsuspend () at soinit.c:27
#1  0x405b7ea0 in __DTOR_END__ ()
#2  0x404bcb99 in __pthread_mutex_lock (mutex=0xbfa00754) at restart.h:32
#3  0x404be15c in __flockfile (stream=0xbfa0076c) at lockfile.c:32
#4  0x4054ecfa in _IO_vfprintf (s=0xbfa0076c, format=0x404b03c2 \
    "%s=%s", ap=0xbfa007ec) at vfprintf.c:906
#5  0x4055a5a3 in _IO_vsprintf (string=0x81efb90 "", format= \
    0x404b03c2"%s=%s", args=0xbfa007ec) at iovsprintf.c:48
#6  0x40555a41 in sprintf (s=0x81efb90 "", format=0x404b03c2 \
    "%s=%s") at sprintf.c:33
#7  0x404af970 in setenv ()
#8  0x4053d5c5 in putenv (string=0x81efb78 "ORA_NET2_DESC=3,6") \
    at ../sysdeps/generic/putenv.c:63
#9  0x404af976 in setenv ()
#10 0x4053d5c5 in putenv (string=0x81efb60 "ORA_NET2_DESC=3,6") \
    at ../sysdeps/generic/putenv.c:63
#11 0x404af976 in setenv ()

...

#130634 0x4053d5c5 in putenv (string=0x8071060 "ORA_NET2_DESC=3,6") \
    at ../sysdeps/generic/putenv.c:63
#130635 0x404af976 in setenv ()
#130636 0x4053d5c5 in putenv (string=0x8071048 "ORA_NET2_DESC=3,6") \
    at ../sysdeps/generic/putenv.c:63
#130637 0x404af976 in setenv ()
#130638 0x4053d5c5 in putenv (string=0x8070388 "ORA_NET2_DESC=3,6") \
    at ../sysdeps/generic/putenv.c:63
#130639 0x401591cf in sntpcall ()
#130640 0x40157311 in ntpcon ()
#130641 0x401559eb in ntconn ()
#130642 0x401460bf in nsopen ()
#130643 0x4013935c in nscall1 ()
#130644 0x40138d26 in nscall ()
#130645 0x4013566f in nricdt ()
#130646 0x401351cf in nricall ()
#130647 0x4011b432 in niotns ()
#130648 0x40117ae9 in nigcall ()
#130649 0x40117957 in osncon ()
#130650 0x400f9fa7 in upiini ()
#130651 0x400eed9e in upiahm ()
#130652 0x400cb34d in kpuatch ()
#130653 0x400ead1f in OCIServerAttach ()
#130654 0x804946e in main () at omnioracle.C:33
(gdb)