10g Signal Handlers and Dynamic Binding Problems on Mac OS X

Question

I have the following env vars set up, and it seems the client libs show a deadl\
ock behavior post installation. SqlPlus exhibits a similar problem with 10g cli\
ent libs on the Mac, since it simply hangs for 20 secs before returning the pro\
mpt. I have G4 10.3.4 Mac, and 3.3 (1640) gcc, and still haunted by this probl\
em...
ORACLE_HOME=/Users/Oracle/10g/orahome
ORACLE=ORACLE_HOME/bin
ORACLE_BASE=/Users/Oracle/10g
DYLD_LIBRARY_PATH=/Users/Oracle/10g/orahome/lib
a) ktrace sqlplus user/pass@db
b) kdump -R | grep sigaction gives:
885 sqlplus 5.877734 CALL sigaction(0x2,0xbffff500,0xbffff570)
885 sqlplus 0.001252 RET sigaction 0
885 sqlplus 0.002032 CALL sigaction(0xd,0xbfff90f0,0xbfff9160)
885 sqlplus 0.001831 RET sigaction 0
885 sqlplus 0.001293 CALL sigaction(0x12,0xbfffb6e0,0xbfffb750)
885 sqlplus 0.001234 RET sigaction 0
885 sqlplus 0.001551 CALL sigaction(0x12,0xbfffbda0,0xbfffbe10)
885 sqlplus 0.001401 RET sigaction 0
885 sqlplus 0.001331 CALL sigaction(0x2,0xbfffd090,0xbfffd100)
885 sqlplus 0.001333 RET sigaction 0
This shows a 5.9 sec delay for the first sigaction, and a full response is received some long 20 secs later on the prompt.
Some feedback from engineering regarding this issue since the 9i release has been:
"This is a known problem with signal handlers and the lazy binding we have on Mac OS X. A small change to how Oracle library's signal
handler is installed using _signal_nobind(3) and
_dyld_lookup_and_bind_fully(3) could help to solve this problem.
The problem that we are trying to avoid is a possible dead lock from
code that could be called in a signal handler when the thread that
gets the signal is in the middle of lazy binding a symbol. So when a
signal handlers installed the default action is to cause it to be
bound fully. This is made very expensive by the mismatch of the
interfaces to signal(3) and segvec(2) like routines which are passed
an address and the dynamic linker that wants a global symbol name. So the end result is to call the routine _dyld_bind_fully_image_containing_address(3) with the address of the signal handler to be bound. Which binds everything in the image (in this case the Oracle shared library).
We have had problems like this before. For example: [This is what is
done in usleep(3)]
usleep()
/* code removed for this example */
setvec(vec, sleepx);
#ifdef __DYNAMIC__
_dyld_lookup_and_bind_fully("_usleep", NULL, NULL);
(void) _sigvec_nobind(SIGALRM, &vec, &ovec);
#else
(void) sigvec(SIGALRM, &vec, &ovec);
#endif
static void sleepx(int unused)
ringring = 1;
The use of _sigvec_nobind(2) (or _signal_nobind(3) ) and the use of
_dyld_lookup_and_bind_fully(3) will cause just the needed symbols used by the signal handler. "
It seems this issue hasn't been resolved in the most recent 10g client release.Can anyone shed some light one this issue?
For better demonstration, here is a series of steps we took here:
sigaction.c - C file produced by "proc sigaction.pc"
sigaction.pc - ProC source file
gcc_sig* - Shell script to compile sigaction.c
ktrace.sigtest - raw ktrace output from running sigtest
ktrace.sqlplus - raw ktrace output from running sqlplus
kdump.sqlplus - output of kdump -R on ktrace.sqlplus
kdump.sigtest - output of kdump -R on ktrace.sigtest
sigaction.lis - auxiliary file produced by proc
1. sigaction.pc:
#include <stdio.h>
#include <stdlib.h>
#include "/Users/oracle/10g/orahome/precomp/public/sqlca.h"
int main(int argc, char **argv) {
char user[30], passwd[30], db[40];
char con_str[100], date[10], *icp;
strcpy(user, "XXXXXXXX");
strcpy(passwd, "XXXXXXXX");
strcpy(db, "db_name");
sprintf(con_str,"%s/%s@%s",user,passwd,db);
EXEC SQL CONNECT :con_str;
EXEC SQL SELECT SYSDATE INTO :date FROM DUAL;
printf("SYSTEM DATE = %s\n",date);
EXEC SQL COMMIT RELEASE;
2. gcc_sig:
#!/bin/sh
CFLAGS="-I$ORACLE_HOME/precomp/public -I/usr/include"
CFLAGS="$CFLAGS -I$ORACLE_HOME/lib -L$ORACLE_HOME/lib"
ORALIBS="-L$ORACLE_HOME/lib -lclntsh $ORACLE_HOME/lib/nautab.o $ORACLE_HOME/lib/naeet.o"
CC="gcc -g"
PROG=$1
OUTPUT=$2
$CC $CFLAGS $PROG -o $OUTPUT $ORALIBS
3. Generate the rest of the output files for your viewing of the results based on the commands provided above.
Thanks!

Answer 1

It's a delay, not a deadlock, that originatesfrom the way Oracle
libraries handle dymaic bindings.to "dynamic" bindings. Maybe prebinding could help ?
export DYLD_PREBIND_DEBUG=1ronr@[email protected]:/Users/ronr
sqlplus "/ as sysdba"dyld: sqlplus: prebinding disabled because library: /Users/oracle/product/server/10.1/lib/libsqlplus.dylib got slid
dyld: in map_image() determined the system shared regions ARE used
dyld: 2 two-level prebound libraries used out of 5
Ronald
http://homepage.mac.com/ik_zelf/oracle/