Programy instalacyjne Oracle Pro * C/OCI dla SIGSEGV/SIGABRT i przyjaciół - dlaczego i jak je wyłączyć?

Question

Podczas korzystania z Pro * C (wbudowany preprocesor SQL z Oracle dla kodu C) lub OCI zauważyłem, że procedura connect/init instaluje niektóre procedury obsługi sygnałów.

Oznacza to, że przed

EXEC SQL CONNECT :username IDENTIFIED BY :password USING :dbspec ; 

lub

OCIEnvNlsCreate() 

mogę sprawdzić, na przykład sygnały te mają następujące ładowarki:

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 

po connect rachunku/init tabela wygląda następująco:

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 

gdzie 0x7eff9e60bdac oznacza sslsshandler() i 0x7eff9ea17f9c oznacza skgesig_sigactionHandler() - oba symbole zdefiniowane w libclntsh.so.11.1 - biblioteka wykonania Oracle.

Jestem zaniepokojony tymi procedurami obsługi sygnałów Oracle, ponieważ wydaje się, że wprowadzają one całkiem pewne niedeterministyczne zachowanie. Oznacza to, że w zależności od systemu operacyjnego, sprzętu i rodzaju segfault/przerwać jakie obserwowano zachowania:

• brzydki StackTrace że nie zawiera dużo przydatnych informacji
• bezpośrednie wyjście z programu wyjścia statusie 1 - bez każdy plik pisanie rdzeń i żaden komunikat o błędzie
• bezpośrednie wyjście z programu exit-status 0 (sic!)

Zwłaszcza ostatnie zachowanie jest groteskowe.

Tak więc, jestem zainteresowany:

• motywacji - dlaczego te obsługi sygnałów zainstalowany przez Oracle?
• jak je wyłączyć? - przynajmniej dla sygnałów, które domyślnie dostarczają plik podstawowy - ponieważ dla mojego przypadku użycia chcę mieć rdzeń w tych okolicznościach (podczas programowania) lub wiarygodny i informacyjny status wyjścia w produkcji
• czy można bezpiecznie nadpisać sygnał Oracle -handler przez np act.sa_handler = SIG_DFL; sigaction(SIGABRT, &act, 0);?
• jakie są wady resetowania SIGABRT/SIGSEGV i znajomych do SIG_DFL po nawiązaniu połączenia?

Answer 1

Uwarunkowania obsługi sygnałów i diagnostyki: w ramce diagnostycznej OCI instalowane są moduły obsługi sygnałów, które mogą wpływać na obsługę sygnałów używaną w aplikacji. Można wyłączyć obsługę sygnałów OCI, ustawiając w pliku sqlnet.ora ustawienie:

DIAG_SIGHANDLER_ENABLED=FALSE 

. Aby uzyskać więcej informacji, patrz "Fault Diagnosability in OCI" w Oracle Call Interface Programmer's Guide.

Spróbuj skonfigurować tę zmienną w sqlnet.ora pliku

Answer 2

bym załatać plik Oracle .so zastąpić ciąg sigaction z nosigactn i utworzyć funkcję no-op w programie o nazwie nosigactn z tym samym podpisem jako sigaction.