[omniORB] omniORB possibly looping

Judy Anderson yduj@harlequin.com
Thu, 25 Feb 99 11:51:04 EST


Oracle does all sorts of excitingly bad things to your interrupt
handlers.  My most recent experience was with HP UX, in which after
oracle returned, the interrupts were all completely messed up.  I
don't know if OmniOrb establishes any interrupt handlers, but it may
well be that you need to invent some horrible kluge such as I did.

What I did was to wrap all my calls to olog in a C function which
would stash the interrupt handler that we had set up, set the handler
for SIGCHLD to SIG_DFL, call olog, and then re-establish our interrupt
handler (using sigaction).  In our particular program we also needed
to make sure that the SA_ONSTACK flag was set for a variety
interrupts, so we also re-establish that flag, which oracle had
invariably trashed.

A similar problem existed on Solaris, but I'm not sure if we needed to
do it on Linux.  Of course, this was not in an OmniOrb application,
and so I don't know if my experiences with oracle's interrupt handling
are relevant to your situation.
					Judy Anderson "yduJ"
					yduJ@harlequin.com
					617-374-2547

    From: Kelly Burkhart <kburk@sky.net>
    Date: Wed, 24 Feb 1999 20:43:50 -0600 (CST)
    
    I have run into a bit of a snag while trying to create an omniORB
    server which connects to Oracle 8 using OCI.  When the server process
    attempts to connect the process appears to hang.
    
    While trying to create a small program that reproduces the error, I found
    that I could reproduce the problem with a simple program that attempts to
    log in to Oracle and contains no omniORB calls at all.  The program when
    linked normally works fine, when linked to omniORB libraries the process
    hangs when attempting to connect to Oracle.
    
    I ran the program under strace and realized that the program forks a
    child, and blocks attempting to read from what must be the new child's 
    stdout.
    
    I then attached to the child program with gdb, looked at the stack
    trace and it looked like the process was looping somewhere in
    libtcpwrapGK.
    
    I'm currently doing a debug compile of omniORB and will attempt to
    sniff around a bit more tomorrow.  I am hoping in the mean time that
    one of you will recognise this problem and point me to a fix by the
    time I read my mail tomorrow evening ;-)
    
    If anyone has some insight please post.  Otherwise I will resume my
    search tomorrow.