适用于SIGSEGV/SIGABRT和朋友的Oracle Pro * C/OCI安装处理程序-为什么以及如何禁用? [英] Oracle Pro*C/OCI install handlers for SIGSEGV/SIGABRT and friends - why, and how to disable?
问题描述
在使用Pro * C(Oracle的嵌入式SQL预处理器,用于C代码)或OCI时,我注意到connect/init例程会安装一些信号处理程序.
这意味着在
之前EXEC SQL CONNECT :username IDENTIFIED BY :password USING :dbspec ;
或a
OCIEnvNlsCreate()
我可以验证例如这些信号是否具有以下处理程序:
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
在connect/init语句之后,该表如下所示:
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
其中0x7eff9e60bdac表示sslsshandler()
,0x7eff9ea17f9c表示skgesig_sigactionHandler()
-在libclntsh.so.11.1
中定义的两个符号-Oracle运行时库.
我担心那些Oracle信号处理程序,因为它们似乎引入了很多不确定性行为.这意味着取决于操作系统,硬件和我观察到的以下行为的段错误/异常终止:
- 一个丑陋的堆栈跟踪,其中没有太多有用的信息
- 具有退出状态1的直接程序退出-无需编写任何核心文件,也没有错误消息
- 直接退出程序,退出状态为0(原文如此!)
特别是最后一个行为是怪诞的.
因此,我感兴趣:
- 动机-为什么Oracle安装了那些信号处理程序?
- 如何禁用它们? -至少对于默认情况下会产生核心文件的信号-因为在我的用例中,我需要在这种情况下(开发期间)或生产中可靠且信息丰富的退出状态使用核心 是否可以安全地通过以下方式覆盖Oracle信号处理程序:
- 连接后将SIGABRT/SIGSEGV和朋友重置为SIG_DFL有什么缺点?
act.sa_handler = SIG_DFL; sigaction(SIGABRT, &act, 0);
吗?
信号处理和诊断框架注意事项: OCI诊断框架会安装信号处理程序,这可能会影响您在应用程序中使用的任何信号处理.您可以通过设置
来禁用OCI信号处理DIAG_SIGHANDLER_ENABLED=FALSE
sqlnet.ora文件中的
.请参阅" OCI中的故障可诊断性".有关信息,请《 Oracle呼叫接口程序员指南》 . >
请尝试在sqlnet.ora文件中配置此环境变量
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
这篇关于适用于SIGSEGV/SIGABRT和朋友的Oracle Pro * C/OCI安装处理程序-为什么以及如何禁用?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!