Question

我正在Linux上开发一个应用程序，我希望以特定频率回溯所有正在运行的线程。所以我的用户定义的信号处理程序SIGUSR1（适用于所有线程）调用backtrace（）。

我在我的信号处理程序中遇到崩溃（SIGSEGV），该处理程序源自backtrace（）调用。我已经在大多数网站上指定了函数的正确参数。 http://linux.die.net/man/3/backtrace

在这种情况下，什么会导致backtrace（）崩溃？

添加更多详情：

是什么让我得出结论，崩溃在内部回溯中是下面的第14帧。 onMySignal是信号处理程序SIGUSR1，它调用backtrace。

onMySignal的示例代码是（从backtrace的linux文档中复制）

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（）中崩溃的实际问题仍然存在。并且不知道它为什么会崩溃..

编辑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（看起来无效）..

Answer 1

documentation for signal handling 定义要从信号处理程序调用的安全函数列表，不得使用任何其他函数，包括backtrace。（在该文档中搜索async-signal-safe）

您可以对先前设置的管道write执行操作，并让线程等待该管道，然后执行回溯。

编辑：

好的，所以backtrace函数返回当前线程的堆栈，所以不能从另一个线程使用，所以我使用单独的线程来做回溯的想法是行不通的。

因此：您可以从信号处理程序中尝试backtrace_symbols_fd。

作为替代方案，您可以使用gdb来获取回溯，而无需在程序中包含代码 - 而且gdb可以轻松处理多个线程。

运行gdb并返回跟踪的Shell脚本：

#!/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"

Answer 2

如Douglas Leeder所述，backtrace不在信号安全呼叫列表中，但在这种情况下，我怀疑问题是由malloc完成的backtrace_symbols，尝试使用不backtrace_symbols_fd的{{1}}仅malloc。（并删除互斥锁调用，信号处理程序不应该睡觉）

修改

从backtrace的来源我可以看出，它本身应该是信号安全的，尽管你可能会超出你的堆栈。

您可能希望查看glibc对libsegfault的实现，以了解它如何处理此案例

是什么导致Linux 64位上的backtrace（）崩溃（SIGSEGV）

编辑23/06/11：更多细节：

2 个答案: