When using Pro*C (a embedded SQL preprocessor from Oracle for C-Code) or OCI I noticed that the connect/init routine installs some signal handlers.
That means before a
EXEC SQL CONNECT :username IDENTIFIED BY :password USING :dbspec ;
or a
OCIEnvNlsCreate()
I can verify that for example those signals have following handlers:
No NAME Pointer SA_SIGINFO SIG_DFL SIG_IGN
―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――
1 SIGHUP (nil) false true false
2 SIGINT (nil) false true false
3 SIGQUIT (nil) false true false
4 SIGILL (nil) false true false
5 SIGTRAP (nil) false true false
6 SIGABRT (nil) false true false
7 SIGBUS (nil) false true false
8 SIGFPE (nil) false true false
9 SIGKILL (nil) false true false
10 SIGUSR1 (nil) false true false
11 SIGSEGV (nil) false true false
12 SIGUSR2 (nil) false true false
13 SIGPIPE (nil) false true false
14 SIGALRM (nil) false true false
After the connect/init statement the table looks like:
No NAME Pointer SA_SIGINFO SIG_DFL SIG_IGN
―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――
1 SIGHUP (nil) false true false
2 SIGINT 0x7eff9e60bdac true false false
3 SIGQUIT 0x7eff9ea17f9c true false false
4 SIGILL 0x7eff9ea17f9c true false false
5 SIGTRAP 0x7eff9ea17f9c true false false
6 SIGABRT 0x7eff9ea17f9c true false false
7 SIGBUS 0x7eff9ea17f9c true false false
8 SIGFPE 0x7eff9ea17f9c true false false
9 SIGKILL (nil) false true false
10 SIGUSR1 (nil) false true false
11 SIGSEGV 0x7eff9ea17f9c true false false
12 SIGUSR2 (nil) false true false
13 SIGPIPE 0x1 true false true
14 SIGALRM (nil) false true false
where 0x7eff9e60bdac denotes sslsshandler() and 0x7eff9ea17f9c denotes skgesig_sigactionHandler() - both symbols defined in libclntsh.so.11.1 - the Oracle runtime library.
I am concerned about those Oracle signal handlers because it seems that they introduce quite some non-deterministic behaviour. That means depending on the OS, hardware and kind of segfault/abort I've observed following behaviour:
- an ugly stacktrace that does not contain much useful information
- direct program exit with exit-status 1 - without any core file writing and no error message
- direct program exit with exit-status 0 (sic!)
Especially the last behaviour is grotesque.
Thus, I am interested in:
- the motivation - why are those signal handlers installed by Oracle?
- how to disable them? - at least for signals that yield a core file by default - because for my use-case I want a core under those circumstances (during development) or a reliable and informative exit status in production
- is it safe to overwrite the Oracle signal-handler via e.g.
act.sa_handler = SIG_DFL; sigaction(SIGABRT, &act, 0);? - what are the disadvantages of resetting SIGABRT/SIGSEGV and friends to SIG_DFL after connect?
Signal handling and diagnostic framework considerations: the OCI diagnostic framework installs signal handlers that may impact any signal handling that you use in your application. You can disable OCI signal handling by setting
DIAG_SIGHANDLER_ENABLED=FALSE
in the sqlnet.ora file. Refer to "Fault Diagnosability in OCI" in Oracle Call Interface Programmer's Guide for information.
Please try to configure this environment variable in sqlnet.ora file
I would patch the Oracle .so file to replace the sigaction string with nosigactn and make a no-op function in your program called nosigactn with the same signature as sigaction.
来源：https://stackoverflow.com/questions/17124881/oracle-proc-oci-install-handlers-for-sigsegv-sigabrt-and-friends-why-and-how