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:
Especially the last behaviour is grotesque.
Thus, I am interested in:
act.sa_handler = SIG_DFL; sigaction(SIGABRT, &act, 0); ?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.
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
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With