gpt4 book ai didi

linux - 是什么让 64 位 Linux 上的 backtrace() 崩溃(SIGSEGV)

转载 作者:IT王子 更新时间:2023-10-29 00:33:33 25 4
gpt4 key购买 nike

我正在 linux 上开发一个应用程序,我想在其中以特定频率回溯所有正在运行的线程。所以我的用户定义的信号处理程序 SIGUSR1(对于所有线程)调用 backtrace()。

我的信号处理程序发生崩溃(SIGSEGV),它源自 backtrace() 调用。我已将正确的参数传递给大多数网站上指定的函数。 http://linux.die.net/man/3/backtrace .

在这种情况下,什么会导致 backtrace() 崩溃?

要添加更多详细信息:

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

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为了更好的同步,我在互斥锁中编写了信号处理程序实现。

@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(看起来无效)..

最佳答案

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

您可以做的是写入您之前设置的管道,并让一个线程等待该管道,然后执行回溯。

编辑:

好的,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"

关于linux - 是什么让 64 位 Linux 上的 backtrace() 崩溃(SIGSEGV),我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/6371028/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com