当我的程序崩溃时如何自动生成堆栈跟踪

Question

我正在使用 GCC 编译器在 Linux 上工作。 当我的 C++ 程序崩溃时，我希望它自动生成堆栈跟踪。

我的程序由许多不同的用户运行，它也可以在 Linux、Windows 和 Macintosh 上运行（所有版本都是使用 gcc 编译的）。

我希望我的程序能够在崩溃时生成堆栈跟踪，并且用户下次运行它时，它会询问他们是否可以将堆栈跟踪发送给我，以便我可以追踪问题。 我可以处理向我发送信息，但我不知道如何生成跟踪字符串。 有任何想法吗？

Answer 1

可能值得一看 Google Breakpad，它是一个跨平台故障转储生成器和处理转储的工具。

Answer 2

某些版本的 libc 包含处理堆栈跟踪的函数； 您也许可以使用它们：

http://www.gnu.org /software/libc/manual/html_node/Backtraces.html

我记得使用 libunwind 很长一段时间不久前获取堆栈跟踪，但您的平台可能不支持它。

Answer 3

我忘记了 GNOME 的“apport”技术，但我不太了解如何使用它。 它用于生成堆栈跟踪和其他处理诊断信息，并可以自动提交错误。 这当然值得检查。

Answer 4

ulimit -c unlimited

是一个系统变量，它将允许在应用程序崩溃后创建核心转储。 在这种情况下，数量不受限制。 在同一目录中查找名为 core 的文件。 确保您在启用调试信息的情况下编译了代码！

问候

Answer 5

作为仅限 Windows 的解决方案，您可以使用 Windows 错误报告。 只需几个注册表项，就可以将其设置为收集用户-模式转储：

从 Windows Server 2008 和 Windows Vista Service Pack 1 (SP1) 开始，可以配置 Windows 错误报告 (WER)，以便在用户模式应用程序崩溃后在本地收集和存储完整的用户模式转储。 [...]

默认情况下不启用此功能。 启用该功能需要管理员权限。 要启用和配置该功能，请使用 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps 项下的以下注册表值。

您可以从具有所需权限的安装程序设置注册表项。

与在客户端上生成堆栈跟踪相比，创建用户模式转储具有以下优点：

• 它已在系统中实现。 您可以如上所述使用 WER，也可以调用 MiniDumpWriteDump 您自己，如果您需要对要转储的信息量进行更细粒度的控制。 （确保从不同的进程调用它。）
• 比堆栈跟踪方式更完整。 其中，它可以包含局部变量、函数参数、其他线程的堆栈、加载的模块等等。 数据量（以及相应的大小）是高度可定制的。
• 无需发送调试符号。 这既大大减少了部署的大小，也使对应用程序进行逆向工程变得更加困难。
• 很大程度上独立于您使用的编译器。 使用 WER 甚至不需要任何代码。 无论哪种方式，获取符号数据库 (PDB) 对于离线分析非常非常有用。 我相信 GCC 可以生成 PDB，或者有工具可以将符号数据库转换为 PDB 格式。

请注意，WER 只能由应用程序崩溃触发（即系统由于未处理的异常而终止进程）。 MiniDumpWriteDump可以随时调用。 如果您需要转储当前状态来诊断崩溃以外的问题，这可能会很有帮助。

如果您想评估小型转储的适用性，则必须阅读：

• 有效的小型转储
• 有效的小型转储（第 2 部分）

Answer 6

我将使用在 Visual Leak Detector。 不过，这只适用于 Win32。

Answer 7

我在这里看到了很多执行信号处理程序然后退出的答案。
这是正确的方法，但请记住一个非常重要的事实：如果您想获取生成的错误的核心转储，则不能调用 exit(status)。 而是调用 abort()！

Answer 8

我发现@tgamblin 解决方案并不完整。
它无法处理 stackoverflow。
我认为因为默认情况下信号处理程序是使用相同的堆栈调用的
SIGSEGV 被抛出两次。 为了保护您需要为信号处理程序注册一个独立的堆栈。

您可以使用下面的代码来检查这一点。 默认情况下，处理程序失败。 使用定义的宏 STACK_OVERFLOW 就可以了。

#include <iostream>
#include <execinfo.h>
#include <signal.h>
#include <stdlib.h>
#include <unistd.h>
#include <string>
#include <cassert>

using namespace std;

//#define STACK_OVERFLOW

#ifdef STACK_OVERFLOW
static char stack_body[64*1024];
static stack_t sigseg_stack;
#endif

static struct sigaction sigseg_handler;

void handler(int sig) {
  cerr << "sig seg fault handler" << endl;
  const int asize = 10;
  void *array[asize];
  size_t size;

  // get void*'s for all entries on the stack
  size = backtrace(array, asize);

  // print out all the frames to stderr
  cerr << "stack trace: " << endl;
  backtrace_symbols_fd(array, size, STDERR_FILENO);
  cerr << "resend SIGSEGV to get core dump" << endl;
  signal(sig, SIG_DFL);
  kill(getpid(), sig);
}

void foo() {
  foo();
}

int main(int argc, char **argv) {
#ifdef STACK_OVERFLOW
  sigseg_stack.ss_sp = stack_body;
  sigseg_stack.ss_flags = SS_ONSTACK;
  sigseg_stack.ss_size = sizeof(stack_body);
  assert(!sigaltstack(&sigseg_stack, nullptr));
  sigseg_handler.sa_flags = SA_ONSTACK;
#else
  sigseg_handler.sa_flags = SA_RESTART;  
#endif
  sigseg_handler.sa_handler = &handler;
  assert(!sigaction(SIGSEGV, &sigseg_handler, nullptr));
  cout << "sig action set" << endl;
  foo();
  return 0;
} 

Answer 9

请参阅 ACE（自适应通信环境）中的堆栈跟踪工具。 它已经涵盖所有主要平台（以及更多）。 该库采用 BSD 风格许可，因此如果您不想使用 ACE，您甚至可以复制/粘贴代码。

Answer 10

我可以帮助Linux版本：可以使用函数backtrace、backtrace_symbols和backtrace_symbols_fd。 请参阅相应的手册页。

Answer 11

*尼克：
您可以拦截 SIGSEGV （通常在崩溃之前引发此信号）并将信息保存到文件中。 （例如，除了可以使用 gdb 进行调试的核心文件之外）。

赢：
从 msdn 检查此。

你还可以查看google的chrome代码，看看它是如何处理崩溃的。 它有一个很好的异常处理机制。

Answer 12

查看：

man 3 backtrace

并且：

#include <exeinfo.h>
int backtrace(void **buffer, int size);

这些是 GNU 扩展。

Answer 13

如果您仍然想像我一样单独进行，您可以链接到 bfd 并避免使用 addr2line，就像我在这里所做的那样：

https://github.com/gnif/LookingGlass/blob/master/common/src/ platform/linux/crash.c

这会产生输出：

[E]        crash.linux.c:170  | crit_err_hdlr                  | ==== FATAL CRASH (a12-151-g28b12c85f4+1) ====
[E]        crash.linux.c:171  | crit_err_hdlr                  | signal 11 (Segmentation fault), address is (nil)
[E]        crash.linux.c:194  | crit_err_hdlr                  | [trace]: (0) /home/geoff/Projects/LookingGlass/client/src/main.c:936 (register_key_binds)
[E]        crash.linux.c:194  | crit_err_hdlr                  | [trace]: (1) /home/geoff/Projects/LookingGlass/client/src/main.c:1069 (run)
[E]        crash.linux.c:194  | crit_err_hdlr                  | [trace]: (2) /home/geoff/Projects/LookingGlass/client/src/main.c:1314 (main)
[E]        crash.linux.c:199  | crit_err_hdlr                  | [trace]: (3) /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb) [0x7f8aa65f809b]
[E]        crash.linux.c:199  | crit_err_hdlr                  | [trace]: (4) ./looking-glass-client(_start+0x2a) [0x55c70fc4aeca]

Answer 14

除了上述答案之外，这里还介绍了如何使 Debian Linux 操作系统生成核心转储

1. 在用户的主文件夹中创建一个“coredumps”文件夹
2. 转到 /etc/security/limits.conf。 在“ ”行下方，键入“soft core unlimited”，如果为 root 启用核心转储，则键入“root soft core unlimited”，以便为核心转储提供无限空间。
3. 注意：“* soft core unlimited”不包括 root，这就是为什么 root 必须在其自己的行中指定。
4. 要检查这些值，请注销，重新登录，然后键入“ulimit -a”。 “核心文件大小”应设置为无限制。
5. 检查 .bashrc 文件（用户和 root，如果适用）以确保其中未设置 ulimit。 否则，上面的值将在启动时被覆盖。
6. 打开/etc/sysctl.conf。
   在底部输入以下内容：“kernel.core_pattern = /home//coredumps/%e_%t.dump”。 （％e将是进程名称，％t将是系统时间）
7. 退出并输入“sysctl -p”以加载新配置
   检查 /proc/sys/kernel/core_pattern 并验证它是否与您刚刚输入的内容匹配。
8. 可以通过在命令行（“ &”）上运行进程来测试核心转储，然后使用“kill -11 ”杀死它。 如果核心转储成功，您将在分段错误指示后看到“(core dumped)”。

Answer 15

gdb -ex 'set confirm off' -ex r -ex bt -ex q <my-program>

Answer 16

在 Linux/unix/MacOSX 上使用核心文件（您可以使用 ulimit 或 兼容的方式启用它们系统调用）。 在 Windows 上使用 Microsoft 错误报告（您可以成为合作伙伴并访问您的应用程序崩溃数据）。

Answer 17

迄今为止我最好的异步信号安全尝试

如果它实际上并不安全，请告诉我。 我还找不到显示行号的方法。

stacktrace_on_signal_safe.cpp

#include <execinfo.h>
#include <signal.h>
#include <stdlib.h>
#include <unistd.h>

#define TRACE_MAX 1024

void handler(int sig) {
    (void)sig;
    void *array[TRACE_MAX];
    size_t size;
    const char msg[] = "failed with a signal\n";

    size = backtrace(array, TRACE_MAX);
    if(write(STDERR_FILENO, msg, sizeof(msg))){};
    backtrace_symbols_fd(array, size, STDERR_FILENO);
    _Exit(1);
}

void my_func_2(void) {
    *((int*)0) = 1;
}

void my_func_1(double f) {
    (void)f;
    my_func_2();
}

void my_func_1(int i) {
    (void)i;
    my_func_2();
}

int main() {
    /* Make a dummy call to `backtrace` to load libgcc because man backrace says:
     *    *  backtrace() and backtrace_symbols_fd() don't call malloc() explicitly, but they are part of libgcc, which gets loaded dynamically when first used.  Dynamic loading usually triggers a call to mal‐
     *       loc(3).  If you need certain calls to these two functions to not allocate memory (in signal handlers, for example), you need to make sure libgcc is loaded beforehand.
     */
    void *dummy[1];
    backtrace(dummy, 1);
    signal(SIGSEGV, handler);

    my_func_1(1);
}

编译并运行：

g++ -ggdb3 -O2 -std=c++11 -Wall -Wextra -pedantic -rdynamic -o stacktrace_on_signal_safe.out stacktrace_on_signal_safe.cpp
./stacktrace_on_signal_safe.out

需要 -rdynamic 来获取函数名称：

failed with a signal
./stacktrace_on_signal_safe.out(_Z7handleri+0x6e)[0x56239398928e]
/lib/x86_64-linux-gnu/libc.so.6(+0x42520)[0x7f04b1459520]
./stacktrace_on_signal_safe.out(main+0x38)[0x562393989118]
/lib/x86_64-linux-gnu/libc.so.6(+0x29d90)[0x7f04b1440d90]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x80)[0x7f04b1440e40]
./stacktrace_on_signal_safe.out(_start+0x25)[0x562393989155]

然后我们可以将其通过管道传输到 c++filt 来分解：

./stacktrace_on_signal_safe.out |& c++filt

给出：

failed with a signal
/stacktrace_on_signal_safe.out(handler(int)+0x6e)[0x55b6df43f28e]
/lib/x86_64-linux-gnu/libc.so.6(+0x42520)[0x7f40d4167520]
./stacktrace_on_signal_safe.out(main+0x38)[0x55b6df43f118]
/lib/x86_64-linux-gnu/libc.so.6(+0x29d90)[0x7f40d414ed90]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x80)[0x7f40d414ee40]
./stacktrace_on_signal_safe.out(_start+0x25)[0x55b6df43f155]

缺少几个级别由于优化，使用 -O0 我们得到更完整的结果：

/stacktrace_on_signal_safe.out(handler(int)+0x76)[0x55d39b68325f]
/lib/x86_64-linux-gnu/libc.so.6(+0x42520)[0x7f4d8ffdd520]
./stacktrace_on_signal_safe.out(my_func_2()+0xd)[0x55d39b6832bb]
./stacktrace_on_signal_safe.out(my_func_1(int)+0x14)[0x55d39b6832f1]
./stacktrace_on_signal_safe.out(main+0x4a)[0x55d39b68333e]
/lib/x86_64-linux-gnu/libc.so.6(+0x29d90)[0x7f4d8ffc4d90]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x80)[0x7f4d8ffc4e40]
./stacktrace_on_signal_safe.out(_start+0x25)[0x55d39b683125]

行号不存在，但我们可以使用 addr2line 获取它们。 这需要在不使用 -rdynamic 的情况下进行构建：

g++ -ggdb3 -O0 -std=c++23 -Wall -Wextra -pedantic -o stacktrace_on_signal_safe.out stacktrace_on_signal_safe.cpp
./stacktrace_on_signal_safe.out |& sed -r 's/.*\(//;s/\).*//' | addr2line -C -e stacktrace_on_signal_safe.out -f

生成：

??
??:0
handler(int)
/home/ciro/stacktrace_on_signal_safe.cpp:14
??
??:0
my_func_2()
/home/ciro/stacktrace_on_signal_safe.cpp:22
my_func_1(i
/home/ciro/stacktrace_on_signal_safe.cpp:33
main
/home/ciro/stacktrace_on_signal_safe.cpp:45
??
??:0
??
??:0
_start
??:?

awk 解析非 -rdynamic+数字。 code> 输出：

./stacktrace_on_signal_safe.out(+0x125f)[0x55984828825f]
/lib/x86_64-linux-gnu/libc.so.6(+0x42520)[0x7f8644a1e520]
./stacktrace_on_signal_safe.out(+0x12bb)[0x5598482882bb]
./stacktrace_on_signal_safe.out(+0x12f1)[0x5598482882f1]
./stacktrace_on_signal_safe.out(+0x133e)[0x55984828833e]
/lib/x86_64-linux-gnu/libc.so.6(+0x29d90)[0x7f8644a05d90]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x80)[0x7f8644a05e40]
./stacktrace_on_signal_safe.out(+0x1125)[0x559848288125]

如果您还想将实际信号编号打印到标准输出，这里有一个异步信号安全实现 int 到字符串： 使用写入或异步安全函数从信号处理程序中打印 int，因为 printf 不是。

在 Ubuntu 22.04 上测试。

C++23

与许多其他答案一样，本节忽略了问题的异步信号安全方面，这可能导致您的代码在崩溃时陷入死锁，这可能严肃点。 我们只能希望有一天 C++ 标准会添加一个类似 boost::stacktrace::safe_dump_to 的函数来一劳永逸地解决这个问题。

这将是通常更优越的 C++ 堆栈跟踪选项，如以下所述：如何在调用某个函数时打印堆栈跟踪，因为它显示行号并自动为我们进行整理。

stacktrace_on_signal.cpp

#include <stacktrace>
#include <iostream>

#include <signal.h>
#include <stdlib.h>
#include <unistd.h>

void handler(int sig) {
    (void)sig;
    /* De-register this signal in the hope of avoiding infinite loops
     * if asyns signal unsafe things fail later on. But can likely still deadlock. */
    signal(sig, SIG_DFL);
    // std::stacktrace::current
    std::cout << std::stacktrace::current();
    // C99 async signal safe version of exit().
    _Exit(1);
}

void my_func_2(void) {
    *((int*)0) = 1;
}

void my_func_1(double f) {
    (void)f;
    my_func_2();
}

void my_func_1(int i) {
    (void)i;
    my_func_2();
}

int main() {
    signal(SIGSEGV, handler);
    my_func_1(1);
}

编译并运行：

g++ -ggdb3 -O2 -std=c++23 -Wall -Wextra -pedantic -o stacktrace_on_signal.out stacktrace_on_signal.cpp -lstdc++_libbacktrace
./stacktrace_on_signal.out

从源代码编译的 GCC 12.1 上的输出，Ubuntu 22.04：

   0# handler(int) at /home/ciro/stacktrace_on_signal.cpp:11
   1#      at :0
   2# my_func_2() at /home/ciro/stacktrace_on_signal.cpp:16
   3#      at :0
   4#      at :0
   5#      at :0
   6#

我认为由于打开了优化，它错过了 my_func_1 ，据我所知，我们通常对此无能为力。 使用 -O0 会更好：

   0# handler(int) at /home/ciro/stacktrace_on_signal.cpp:11
   1#      at :0
   2# my_func_2() at /home/ciro/stacktrace_on_signal.cpp:16
   3# my_func_1(int) at /home/ciro/stacktrace_on_signal.cpp:26
   4#      at /home/ciro/stacktrace_on_signal.cpp:31
   5#      at :0
   6#      at :0
   7#      at :0
   8#

但不确定为什么 main 没有出现在那里。

backtrace_simple

https://github.com/gcc-mirror/gcc/blob/releases/gcc-12.1.0/libstdc%2B %2B-v3/src/libbacktrace/backtrace-supported.h.in#L45 提到 backtrace_simple 是安全的：

/* BACKTRACE_USES_MALLOC will be #define'd as 1 if the backtrace
   library will call malloc as it works, 0 if it will call mmap
   instead.  This may be used to determine whether it is safe to call
   the backtrace functions from a signal handler.  In general this
   only applies to calls like backtrace and backtrace_pcinfo.  It does
   not apply to backtrace_simple, which never calls malloc.  It does
   not apply to backtrace_print, which always calls fprintf and
   therefore malloc.  */

但它看起来使用起来不太方便，主要是一个内部工具。

std::basic_stacktrace

这是 std::stacktrace 的基础：https://en.cppreference.com/w/cpp/utility/basic_stacktrace

它有一个分配器参数，cppreference 描述为：

提供对自定义分配器的支持，以便在热路径或嵌入式环境中使用 basic_stacktrace。 用户可以在堆栈上或其他合适的地方分配 stacktrace_entry 对象。

所以我想知道 basic_stacktrace 本身是否是异步信号安全的，并且是否不可能制作一个也带有自定义分配器的 std::stacktrace 版本，例如：

• 写入磁盘上的文件，如 boost::stacktrace::safe_dump_to
• 或写入某个预先分配的具有最大大小的堆栈缓冲区

https://apolukhin.github.io/papers/stacktrace_r1.html 可能是收到的提案，提到：

关于信号安全的注意事项：该提案并不试图提供用于捕获和解码堆栈跟踪的信号安全解决方案。 目前，此类功能在某些流行平台上无法实现。 然而，本文试图提供可扩展的解决方案，有一天可能通过提供信号安全分配器并更改堆栈跟踪实现细节来实现信号安全。

只是获取核心转储？

核心转储允许您使用 GDB 检查内存：当程序具有命令行参数时，如何使用 GDB 分析程序的核心转储文件？ 所以它比仅仅拥有痕迹更强大。

只需确保正确启用它，特别是在 Ubuntu 22.04 上，您需要：

echo 'core' | sudo tee /proc/sys/kernel/core_pattern

或者要学习使用 apport，另请参阅：https://askubuntu.com/questions/1349047/where-do-i-find -core-dump-files-and-how-do-i-view-and-analyze-the-backtrace-st/1442665#1442665

Answer 18

对于 Linux 和 Mac OS X，如果您使用 gcc 或任何使用 glibc 的编译器，则可以使用 execinfo.h 中的 backtrace() 函数来打印堆栈跟踪并在以下情况下正常退出：你会遇到分段错误。 文档可以在libc 手册中找到。

下面是一个示例程序，它安装 SIGSEGV 处理程序，并在出现段错误时将堆栈跟踪打印到 stderr。 这里的 baz() 函数会导致触发处理程序的段错误：

#include <stdio.h>
#include <execinfo.h>
#include <signal.h>
#include <stdlib.h>
#include <unistd.h>


void handler(int sig) {
  void *array[10];
  size_t size;

  // get void*'s for all entries on the stack
  size = backtrace(array, 10);

  // print out all the frames to stderr
  fprintf(stderr, "Error: signal %d:\n", sig);
  backtrace_symbols_fd(array, size, STDERR_FILENO);
  exit(1);
}

void baz() {
 int *foo = (int*)-1; // make a bad pointer
  printf("%d\n", *foo);       // causes segfault
}

void bar() { baz(); }
void foo() { bar(); }


int main(int argc, char **argv) {
  signal(SIGSEGV, handler);   // install our handler
  foo(); // this will call foo, bar, and baz.  baz segfaults.
}

使用 -g -rdynamic 进行编译会在输出中获取符号信息，glibc 可以使用它来制作一个漂亮的符号信息。 stacktrace：

$ gcc -g -rdynamic ./test.c -o test

执行此命令会得到以下输出：

$ ./test
Error: signal 11:
./test(handler+0x19)[0x400911]
/lib64/tls/libc.so.6[0x3a9b92e380]
./test(baz+0x14)[0x400962]
./test(bar+0xe)[0x400983]
./test(foo+0xe)[0x400993]
./test(main+0x28)[0x4009bd]
/lib64/tls/libc.so.6(__libc_start_main+0xdb)[0x3a9b91c4bb]
./test[0x40086a]

这显示了堆栈中每个帧来自的加载模块、偏移量和函数。 在这里，您可以看到堆栈顶部的信号处理程序，以及 main 之前的 libc 函数以及 main、foo、酒吧和baz。

Answer 19

它甚至比“man backtrace”更容易，有一个文档很少的库（特定于 GNU）与 glibc 一起分发为 libSegFault.so，我相信它是由 Ulrich Drepper 编写的，用于支持程序 catchsegv（请参阅“man catchsegv”）。

这给了我们3种可能性。 而不是运行“program -o hai”：

1. 在 catchsegv 中运行：

   $ catchsegv 程序 -o hai 
     

2. 在运行时与 libSegFault 链接：

   $ LD_PRELOAD=/lib/libSegFault.so 程序 -o hai 
     

3. 在编译时与 libSegFault 链接：

   $ gcc -g1 -lSegFault -o 程序program.cc 
     $ 程序-o hai 
     

在所有 3 种情况下，您将通过较少的优化（gcc -O0 或 -O1）和调试符号（gcc -g）获得更清晰的回溯。 否则，您最终可能会得到一堆内存地址。

您还可以通过以下方式捕获更多堆栈跟踪信号：

$ export SEGFAULT_SIGNALS="all"       # "all" signals
$ export SEGFAULT_SIGNALS="bus abrt"  # SIGBUS and SIGABRT

输出将如下所示（请注意底部的回溯）：

*** Segmentation fault Register dump:

 EAX: 0000000c   EBX: 00000080   ECX:
00000000   EDX: 0000000c  ESI:
bfdbf080   EDI: 080497e0   EBP:
bfdbee38   ESP: bfdbee20

 EIP: 0805640f   EFLAGS: 00010282

 CS: 0073   DS: 007b   ES: 007b   FS:
0000   GS: 0033   SS: 007b

 Trap: 0000000e   Error: 00000004  
OldMask: 00000000  ESP/signal:
bfdbee20   CR2: 00000024

 FPUCW: ffff037f   FPUSW: ffff0000  
TAG: ffffffff  IPOFF: 00000000  
CSSEL: 0000   DATAOFF: 00000000  
DATASEL: 0000

 ST(0) 0000 0000000000000000   ST(1)
0000 0000000000000000  ST(2) 0000
0000000000000000   ST(3) 0000
0000000000000000  ST(4) 0000
0000000000000000   ST(5) 0000
0000000000000000  ST(6) 0000
0000000000000000   ST(7) 0000
0000000000000000

Backtrace:
/lib/libSegFault.so[0xb7f9e100]
??:0(??)[0xb7fa3400]
/usr/include/c++/4.3/bits/stl_queue.h:226(_ZNSt5queueISsSt5dequeISsSaISsEEE4pushERKSs)[0x805647a]
/home/dbingham/src/middle-earth-mud/alpha6/src/engine/player.cpp:73(_ZN6Player5inputESs)[0x805377c]
/home/dbingham/src/middle-earth-mud/alpha6/src/engine/socket.cpp:159(_ZN6Socket4ReadEv)[0x8050698]
/home/dbingham/src/middle-earth-mud/alpha6/src/engine/socket.cpp:413(_ZN12ServerSocket4ReadEv)[0x80507ad]
/home/dbingham/src/middle-earth-mud/alpha6/src/engine/socket.cpp:300(_ZN12ServerSocket4pollEv)[0x8050b44]
/home/dbingham/src/middle-earth-mud/alpha6/src/engine/main.cpp:34(main)[0x8049a72]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe5)[0xb7d1b775]
/build/buildd/glibc-2.9/csu/../sysdeps/i386/elf/start.S:122(_start)[0x8049801]

如果您想了解详细信息，不幸的是，最好的源是源：请参阅 http://sourceware.org/git/?p= glibc.git;a=blob;f=debug/segfault.c 及其父目录 http://sourceware.org/git/?p=glibc.git;a=tree;f=debug

Answer 20

Linux

虽然使用 execinfo.h 中的 backtrace() 函数来打印堆栈跟踪并在出现分段错误时正常退出，但 已经被建议，我没有看到任何提及确保生成的回溯指向实际位置所需的复杂性错误（至少对于某些架构 - x86 和 ARM）。

当您进入信号处理程序时，堆栈帧链中的前两个条目包含信号处理程序内部的返回地址和 libc 中 sigaction() 内部的一个返回地址。 信号之前调用的最后一个函数的堆栈帧（即故障位置）丢失。

代码

#ifndef _GNU_SOURCE
#define _GNU_SOURCE
#endif
#ifndef __USE_GNU
#define __USE_GNU
#endif

#include <execinfo.h>
#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <ucontext.h>
#include <unistd.h>

/* This structure mirrors the one found in /usr/include/asm/ucontext.h */
typedef struct _sig_ucontext {
 unsigned long     uc_flags;
 ucontext_t        *uc_link;
 stack_t           uc_stack;
 sigcontext_t      uc_mcontext;
 sigset_t          uc_sigmask;
} sig_ucontext_t;

void crit_err_hdlr(int sig_num, siginfo_t * info, void * ucontext)
{
 void *             array[50];
 void *             caller_address;
 char **            messages;
 int                size, i;
 sig_ucontext_t *   uc;

 uc = (sig_ucontext_t *)ucontext;

 /* Get the address at the time the signal was raised */
#if defined(__i386__) // gcc specific
 caller_address = (void *) uc->uc_mcontext.eip; // EIP: x86 specific
#elif defined(__x86_64__) // gcc specific
 caller_address = (void *) uc->uc_mcontext.rip; // RIP: x86_64 specific
#else
#error Unsupported architecture. // TODO: Add support for other arch.
#endif

 fprintf(stderr, "signal %d (%s), address is %p from %p\n", 
  sig_num, strsignal(sig_num), info->si_addr, 
  (void *)caller_address);

 size = backtrace(array, 50);

 /* overwrite sigaction with caller's address */
 array[1] = caller_address;

 messages = backtrace_symbols(array, size);

 /* skip first stack frame (points here) */
 for (i = 1; i < size && messages != NULL; ++i)
 {
  fprintf(stderr, "[bt]: (%d) %s\n", i, messages[i]);
 }

 free(messages);

 exit(EXIT_FAILURE);
}

int crash()
{
 char * p = NULL;
 *p = 0;
 return 0;
}

int foo4()
{
 crash();
 return 0;
}

int foo3()
{
 foo4();
 return 0;
}

int foo2()
{
 foo3();
 return 0;
}

int foo1()
{
 foo2();
 return 0;
}

int main(int argc, char ** argv)
{
 struct sigaction sigact;

 sigact.sa_sigaction = crit_err_hdlr;
 sigact.sa_flags = SA_RESTART | SA_SIGINFO;

 if (sigaction(SIGSEGV, &sigact, (struct sigaction *)NULL) != 0)
 {
  fprintf(stderr, "error setting signal handler for %d (%s)\n",
    SIGSEGV, strsignal(SIGSEGV));

  exit(EXIT_FAILURE);
 }

 foo1();

 exit(EXIT_SUCCESS);
}

输出

signal 11 (Segmentation fault), address is (nil) from 0x8c50
[bt]: (1) ./test(crash+0x24) [0x8c50]
[bt]: (2) ./test(foo4+0x10) [0x8c70]
[bt]: (3) ./test(foo3+0x10) [0x8c8c]
[bt]: (4) ./test(foo2+0x10) [0x8ca8]
[bt]: (5) ./test(foo1+0x10) [0x8cc4]
[bt]: (6) ./test(main+0x74) [0x8d44]
[bt]: (7) /lib/libc.so.6(__libc_start_main+0xa8) [0x40032e44]

在信号处理程序中调用 backtrace() 函数的所有危险仍然存在，不应被忽视，但我发现这里描述的功能对于调试崩溃非常有帮助。

值得注意的是，我提供的示例是在 Linux x86 上开发/测试的。 我还在 ARM 上使用 uc_mcontext.arm_pc 而不是 uc_mcontext.eip 成功实现了这一点。

这是我了解此实现的详细信息的文章的链接：
http://www.linuxjournal.com/article/6391

Answer 21

即使正确答案< /a> 已提供，描述如何使用 GNU libc backtrace() 函数¹，我提供了 我自己的答案描述了如何确保信号处理程序的回溯指向故障的实际位置²，我没有看到任何提及demangling< /a> 回溯的 C++ 符号输出。

从 C++ 程序获取回溯时，可以通过 c++filt¹ 运行输出来对符号进行解调，或者使用 abi::__cxa_demangle¹ 直接。

• ¹ Linux 和 Linux 操作系统
  _{请注意，c++filt 和 __cxa_demangle 是 GCC 特定的}
• ² Linux

---

以下 C++ Linux 示例使用相同的信号处理程序作为我的其他答案< /a> 并演示如何使用 c++filt 来对符号进行分解。

代码：

class foo
{
public:
    foo() { foo1(); }

private:
    void foo1() { foo2(); }
    void foo2() { foo3(); }
    void foo3() { foo4(); }
    void foo4() { crash(); }
    void crash() { char * p = NULL; *p = 0; }
};

int main(int argc, char ** argv)
{
    // Setup signal handler for SIGSEGV
    ...

    foo * f = new foo();
    return 0;
}

输出 (./test)：

signal 11 (Segmentation fault), address is (nil) from 0x8048e07
[bt]: (1) ./test(crash__3foo+0x13) [0x8048e07]
[bt]: (2) ./test(foo4__3foo+0x12) [0x8048dee]
[bt]: (3) ./test(foo3__3foo+0x12) [0x8048dd6]
[bt]: (4) ./test(foo2__3foo+0x12) [0x8048dbe]
[bt]: (5) ./test(foo1__3foo+0x12) [0x8048da6]
[bt]: (6) ./test(__3foo+0x12) [0x8048d8e]
[bt]: (7) ./test(main+0xe0) [0x8048d18]
[bt]: (8) ./test(__libc_start_main+0x95) [0x42017589]
[bt]: (9) ./test(__register_frame_info+0x3d) [0x8048981]

分解输出 (./test 2>& 1 | c++filt)：

signal 11 (Segmentation fault), address is (nil) from 0x8048e07
[bt]: (1) ./test(foo::crash(void)+0x13) [0x8048e07]
[bt]: (2) ./test(foo::foo4(void)+0x12) [0x8048dee]
[bt]: (3) ./test(foo::foo3(void)+0x12) [0x8048dd6]
[bt]: (4) ./test(foo::foo2(void)+0x12) [0x8048dbe]
[bt]: (5) ./test(foo::foo1(void)+0x12) [0x8048da6]
[bt]: (6) ./test(foo::foo(void)+0x12) [0x8048d8e]
[bt]: (7) ./test(main+0xe0) [0x8048d18]
[bt]: (8) ./test(__libc_start_main+0x95) [0x42017589]
[bt]: (9) ./test(__register_frame_info+0x3d) [0x8048981]

---

以下内容基于我的 原始答案并且可以替换上面示例中的信号处理程序以演示如何abi::__cxa_demangle 可用于对符号进行分解。 该信号处理程序产生与上面示例相同的分解输出。

代码：

void crit_err_hdlr(int sig_num, siginfo_t * info, void * ucontext)
{
    sig_ucontext_t * uc = (sig_ucontext_t *)ucontext;

    void * caller_address = (void *) uc->uc_mcontext.eip; // x86 specific

    std::cerr << "signal " << sig_num 
              << " (" << strsignal(sig_num) << "), address is " 
              << info->si_addr << " from " << caller_address 
              << std::endl << std::endl;

    void * array[50];
    int size = backtrace(array, 50);

    array[1] = caller_address;

    char ** messages = backtrace_symbols(array, size);    

    // skip first stack frame (points here)
    for (int i = 1; i < size && messages != NULL; ++i)
    {
        char *mangled_name = 0, *offset_begin = 0, *offset_end = 0;

        // find parantheses and +address offset surrounding mangled name
        for (char *p = messages[i]; *p; ++p)
        {
            if (*p == '(') 
            {
                mangled_name = p; 
            }
            else if (*p == '+') 
            {
                offset_begin = p;
            }
            else if (*p == ')')
            {
                offset_end = p;
                break;
            }
        }

        // if the line could be processed, attempt to demangle the symbol
        if (mangled_name && offset_begin && offset_end && 
            mangled_name < offset_begin)
        {
            *mangled_name++ = '\0';
            *offset_begin++ = '\0';
            *offset_end++ = '\0';

            int status;
            char * real_name = abi::__cxa_demangle(mangled_name, 0, 0, &status);

            // if demangling is successful, output the demangled function name
            if (status == 0)
            {    
                std::cerr << "[bt]: (" << i << ") " << messages[i] << " : " 
                          << real_name << "+" << offset_begin << offset_end 
                          << std::endl;

            }
            // otherwise, output the mangled function name
            else
            {
                std::cerr << "[bt]: (" << i << ") " << messages[i] << " : " 
                          << mangled_name << "+" << offset_begin << offset_end 
                          << std::endl;
            }
            free(real_name);
        }
        // otherwise, print the whole line
        else
        {
            std::cerr << "[bt]: (" << i << ") " << messages[i] << std::endl;
        }
    }
    std::cerr << std::endl;

    free(messages);

    exit(EXIT_FAILURE);
}

Answer 22

您没有指定您的操作系统，因此很难回答。 如果您使用的是基于 gnu libc 的系统，您也许可以使用 libc 函数 backtrace()。

GCC 还有两个内置函数可以帮助您，但它们可能会也可能不会在您的架构上完全实现，它们是 __builtin_frame_address 和 __builtin_return_address。 两者都需要立即整数级别（立即，我的意思是它不能是变量）。 如果给定级别的 __builtin_frame_address 不为零，则可以安全地获取同一级别的返回地址。

Answer 23

需要注意的是，一旦生成了 core 文件，您就需要使用 gdb 工具来查看它。 为了使 gdb 理解您的核心文件，您必须告诉 gcc 使用调试符号来检测二进制文件：为此，您可以使用 -g 标志进行编译：

$ g++ -g prog.cpp -o prog

然后，您可以设置“ulimit -c unlimited”以让它转储一个核心，或者只是在 gdb 中运行你的程序。 我更喜欢第二种方法：

$ gdb ./prog
... gdb startup output ...
(gdb) run
... program runs and crashes ...
(gdb) where
... gdb outputs your stack trace ...

我希望这会有所帮助。

Answer 24

感谢热情的极客让我注意到 addr2line 实用程序。

我编写了一个快速而肮脏的脚本来处理此处提供的答案的输出：
（非常感谢 jschmier！）使用 addr2line 实用程序。

该脚本接受一个参数：包含 jschmier 实用程序输出的文件的名称。

对于跟踪的每个级别，输出应打印如下内容：

BACKTRACE:  testExe 0x8A5db6b
FILE:       pathToFile/testExe.C:110
FUNCTION:   testFunction(int) 
   107  
   108           
   109           int* i = 0x0;
  *110           *i = 5;
   111      
   112        }
   113        return i;

代码：

#!/bin/bash

LOGFILE=$1

NUM_SRC_CONTEXT_LINES=3

old_IFS=$IFS  # save the field separator           
IFS=
\n'     # new field separator, the end of line           

for bt in `cat $LOGFILE | grep '\[bt\]'`; do
   IFS=$old_IFS     # restore default field separator 
   printf '\n'
   EXEC=`echo $bt | cut -d' ' -f3 | cut -d'(' -f1`  
   ADDR=`echo $bt | cut -d'[' -f3 | cut -d']' -f1`
   echo "BACKTRACE:  $EXEC $ADDR"
   A2L=`addr2line -a $ADDR -e $EXEC -pfC`
   #echo "A2L:        $A2L"

   FUNCTION=`echo $A2L | sed 's/\<at\>.*//' | cut -d' ' -f2-99`
   FILE_AND_LINE=`echo $A2L | sed 's/.* at //'`
   echo "FILE:       $FILE_AND_LINE"
   echo "FUNCTION:   $FUNCTION"

   # print offending source code
   SRCFILE=`echo $FILE_AND_LINE | cut -d':' -f1`
   LINENUM=`echo $FILE_AND_LINE | cut -d':' -f2`
   if ([ -f $SRCFILE ]); then
      cat -n $SRCFILE | grep -C $NUM_SRC_CONTEXT_LINES "^ *$LINENUM\>" | sed "s/ $LINENUM/*$LINENUM/"
   else
      echo "File not found: $SRCFILE"
   fi
   IFS=
\n'     # new field separator, the end of line           
done

IFS=$old_IFS     # restore default field separator 

Answer 25

ulimit -c 设置 unix 上的核心文件大小限制。 默认情况下，核心文件大小限制为 0。您可以使用 ulimit -a 查看您的 ulimit 值。

另外，如果您从 gdb 中运行程序，它会因“分段违规”（SIGSEGV，通常当您访问未分配的内存时）而停止您的程序，或者您可以设置断点。

ddd 和 nemiver 是 gdb 的前端，这使得新手更容易使用它。

Answer 26

看起来在最后一个 C++ boost 版本之一中出现的库正好提供了您想要的内容，可能代码是多平台的。
它是 boost::stacktrace，您可以使用就像 如 boost 示例：

#include <filesystem>
#include <sstream>
#include <fstream>
#include <signal.h>     // ::signal, ::raise
#include <boost/stacktrace.hpp>

const char* backtraceFileName = "./backtraceFile.dump";

void signalHandler(int)
{
    ::signal(SIGSEGV, SIG_DFL);
    ::signal(SIGABRT, SIG_DFL);
    boost::stacktrace::safe_dump_to(backtraceFileName);
    ::raise(SIGABRT);
}

void sendReport()
{
    if (std::filesystem::exists(backtraceFileName))
    {
        std::ifstream file(backtraceFileName);

        auto st = boost::stacktrace::stacktrace::from_dump(file);
        std::ostringstream backtraceStream;
        backtraceStream << st << std::endl;

        // sending the code from st

        file.close();
        std::filesystem::remove(backtraceFileName);
    }
}

int main()
{
    ::signal(SIGSEGV, signalHandler);
    ::signal(SIGABRT, signalHandler);

    sendReport();
    // ... rest of code
}

在 Linux 中，您编译上面的代码：

g++ --std=c++17 file.cpp -lstdc++fs -lboost_stacktrace_backtrace -ldl -lbacktrace

从 boost 文档复制的示例回溯一个>：

0# bar(int) at /path/to/source/file.cpp:70
1# bar(int) at /path/to/source/file.cpp:70
2# bar(int) at /path/to/source/file.cpp:70
3# bar(int) at /path/to/source/file.cpp:70
4# main at /path/to/main.cpp:93
5# __libc_start_main in /lib/x86_64-linux-gnu/libc.so.6
6# _start

Answer 27

城里的新国王已经到来
https://github.com/bombela/backward-cpp

1 个要放置在代码中的标头1 个要安装的库。

我个人使用这个函数来称呼它

#include "backward.hpp"
void stacker() {

using namespace backward;
StackTrace st;


st.load_here(99); //Limit the number of trace depth to 99
st.skip_n_firsts(3);//This will skip some backward internal function from the trace

Printer p;
p.snippet = true;
p.object = true;
p.color = true;
p.address = true;
p.print(st, stderr);
}

Answer 28

我已经研究这个问题有一段时间了。

并深埋在 Google 性能工具自述文件

http://code 中。 google.com/p/google-perftools/source/browse/trunk/README

讨论 libunwind

http: //www.nongnu.org/libunwind/

很想听听这个库的意见。

-rdynamic 的问题在于，在某些情况下它会相对显着地增加二进制文件的大小

Answer 29

您可以使用 DeathHandler - 小型 C++ 类，它可以为您完成所有操作，可靠。

Answer 30

忘记更改源代码并使用 backtrace() 函数或宏进行一些修改 - 这些只是糟糕的解决方案。

作为一个正常工作的解决方案，我建议：

1. 使用“-g”标志编译程序，将调试符号嵌入到二进制文件中（不用担心这不会影响您的性能）。
2. 在 Linux 上运行下一个命令：“ulimit -c unlimited” - 允许系统进行大型故障转储。
3. 当您的程序崩溃时，在工作目录中您将看到文件“core”。
4. 运行下一个命令将回溯打印到标准输出： gdb -batch -ex "backtrace" ./your_program_exe ./core

这将以人类可读的方式打印程序的正确可读回溯（带有源文件名和行号）。
此外，这种方法将使您可以自由地实现系统自动化：
有一个简短的脚本来检查进程是否创建了核心转储，然后通过电子邮件将回溯发送给开发人员，或将其记录到某些日志系统中。