что делает сбой backtrace () (SIGSEGV) в 64-битной Linux - PullRequest
Новая
       0

что делает сбой backtrace () (SIGSEGV) в 64-битной Linux

5 голосов
/ 16 июня 2011

Я разрабатываю приложение на Linux, где я хотел, чтобы была обратная трассировка всех запущенных потоков на определенной частоте. поэтому мой пользовательский обработчик сигнала SIGUSR1 (для всех потоков) вызывает backtrace ().

Я получаю сбой (SIGSEGV) в моем обработчике сигналов, который возник из вызова backtrace (). Я передал правильные аргументы функции, как указано на большинстве сайтов. http://linux.die.net/man/3/backtrace.

что может привести к сбою backtrace () в этом случае?

Чтобы добавить больше деталей:

То, что заставляет меня сделать вывод, что сбой происходит внутри трассировки, это кадр 14 ниже. onMySignal - это обработчик сигнала SIGUSR1, который вызывает backtrace.

Пример кода onMySignal (скопирован из документации Linux по backtrace) 

pthread_mutex_lock( &sig_mutex );

int j, nptrs;
    #define SIZE 100
        void *buffer[100] = {NULL};//or void *buffer[100];
        char **strings;
       nptrs = backtrace(buffer, SIZE);
           pthread_mutex_unlock( &sig_mutex );

(gdb) where
#0  0x00000037bac0e9dd in raise () from 
#1  0x00002aaabda936b2 in skgesigOSCrash () from 
#2  0x00002aaabdd31705 in kpeDbgSignalHandler () 
#3  0x00002aaabda938c2 in skgesig_sigactionHandler () 
#4  <signal handler called>
#5  0x00000037ba030265 in raise () from 
#6  0x00000037ba031d10 in abort () from 
#7  0x00002b6cef82efd7 in os::abort(bool) () from 
#8  0x00002b6cef98205d in VMError::report_and_die() ()
#9  0x00002b6cef835655 in JVM_handle_linux_signal () 
#10 0x00002b6cef831bae in signalHandler(int, siginfo*, void*) ()
#11 <signal handler called>
#12 0x00000037be407638 in ?? () 
#13 0x00000037be4088bb in _Unwind_Backtrace () 
#14 0x00000037ba0e5fa8 in backtrace () 
#15 0x00002aaaaae3875f in onMySignal (signum=10,info=0x4088ec80, context=0x4088eb50)   
#16 <signal handler called>
#17 0x00002aaab4aa8acb in mxSession::setPartition(int)
#18 0x0000000000000001 in ?? ()
#19 0x0000000000000000 in ?? ()
(gdb)

надеюсь, это прояснит проблему ..

@ janneb Я написал реализацию обработчика сигнала в блокировке Mutex для лучшей синхронизации.

@ janneb я не нашел в Документе, указывающем, что API backtrace_symbols / backtrace является async_signal_safe или нет. и должны ли они использоваться в обработчике сигналов или нет.

Тем не менее я удалил backtrace_symbols из моего обработчика сигналов и не использую его где-либо ... но моя настоящая проблема сбоя в backtrace () persit. и понятия не имею, почему он падает ..

Редактировать 23/06/11: подробнее: 

(gdb) where
#0  0x00000037bac0e9dd in raise () from 
#1  0x00002aaab98a36b2 in skgesigOSCrash () from 
#2  0x00002aaab9b41705 in kpeDbgSignalHandler () from 
#3  0x00002aaab98a38c2 in skgesig_sigactionHandler () from 
#4  <signal handler called>
#5  0x00000037ba030265 in raise () from 
#6  0x00000037ba031d10 in abort () from 
#7  0x00002ac003803fd7 in os::abort(bool) () from
#8  0x00002ac00395705d in VMError::report_and_die() () from 
#9  0x00002ac00380a655 in JVM_handle_linux_signal () from 
#10 0x00002ac003806bae in signalHandler(int, siginfo*, void*) () from 
#11 <signal handler called>
#12 0x00000037be407638 in ?? () from libgcc_s.so.1
#13 0x00000037be4088bb in _Unwind_Backtrace () from libgcc_s.so.1
#14 0x00000037ba0e5fa8 in backtrace () from libc.so.6
#15 0x00002aaaaae3875f in onMyBacktrace (signum=10, info=0x415d0eb0, context=0x415d0d80)
#16 <signal handler called>
#17 0x00000037ba071fa8 in _int_free () from libc.so.6
#18 0x00000000000007e0 in ?? ()
#19 0x000000005aab01a0 in ?? ()
#20 0x000000000000006f in ?? ()
#21 0x00000037ba075292 in realloc () from libc.so.6
#22 0x00002aaab6248c4e in Memory::reallocMemory(void*, unsigned long, char const*, int) ()

произошел сбой при выполнении realloc, и один из адресов был похож на 0x00000000000007e0 (выглядит неверно) ..

Ответы [ 2 ]

2 голосов
/ 20 июня 2011

Как заявил Дуглас Лидер, backtrace не входит в список сигнальных безопасных вызовов, хотя в этом случае я подозреваю, что проблема заключается в malloc, выполненном backtrace_symbols, попробуйте использовать backtrace_symbols_fd, что делаетне звоните malloc, только write.(и отбрасывать вызовы мьютекса, обработчики сигналов не должны спать)

РЕДАКТИРОВАТЬ

Из того, что я могу сказать из источника для backtrace, это должно быть сигнально безопасно, хотя возможно, что вы переполняете свой стек.

Возможно, вы захотите взглянуть на реализацию glibc для libsegfault , чтобы увидеть, как он обрабатывает этот случай

2 голосов
/ 20 июня 2011

Документация для обработки сигналов определяет список безопасных функций для вызова из обработчика сигналов, вы не должны использовать никакие другие функции, включая backtrace.(найдите async-signal-safe в этом документе)

Что вы можете сделать, это write к каналу, который вы ранее настроили, и получить поток, ожидающий этот канал, который затем выполняет обратную трассировку.

EDIT:

Хорошо, так что функция backtrace возвращает стек текущего потока, поэтому не может использоваться из другого потока, поэтому моя идея использовать отдельный поток для обратного следования не будетработа.

Поэтому: вы можете попробовать backtrace_symbols_fd из вашего обработчика сигнала.

В качестве альтернативы вы можете использовать gdb, чтобы получить обратную трассировку, без необходимости иметь код в вашей программе -gdb может легко обрабатывать несколько потоков.

Сценарий оболочки для запуска GDB и получения трассировок: 

#!/bin/bash
PID="$1"
[ -d "/proc/$PID" ] || PID=$(pgrep $1)
[ -d "/proc/$PID" ] || { echo "Can't find process: $PID" >&2 ; exit 1 ; }

[ -d "$TMPDIR" ] || TMPDIR=/tmp

BATCH=$(mktemp $TMPDIR/pstack.gdb.XXXXXXXXXXXXX)
echo "thread apply all bt" >"$BATCH"
echo "quit" >>"$BATCH"
gdb "/proc/$PID/exe" "$PID" -batch -x "$BATCH" </dev/null
rm "$BATCH"
...