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

Question

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

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

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

Answer 1

对于 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 可以使用这些信息来制作漂亮的堆栈跟踪：

$ 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 、 foo 、 bar和baz之外的main之前的 libc 函数。

Answer 2

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

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

1. 在 catchsegv 中运行：

    $ catchsegv program -o hai

2. 在运行时与 libSegFault 链接：

    $ LD_PRELOAD=/lib/libSegFault.so program -o hai

3. 在编译时与 libSegFault 链接：

    $ gcc -g1 -lSegFault -o program program.cc $ program -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 3

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 for x86 上开发/测试的。 我还使用uc_mcontext.arm_pc而不是uc_mcontext.eip在 ARM 上成功实现了这一点。

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

Answer 4

即使提供了描述如何使用 GNU libc backtrace()函数¹的正确答案，并且我提供了自己的答案，描述了如何确保来自信号处理程序的回溯指向故障²的实际位置，但我不'没有看到任何提及从回溯中输出的对 C++ 符号的去处理。

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

• ¹ Linux & OS X_{请注意， c++filt和__cxa_demangle是 GCC 特定的}
• ² Linux

---

以下 C++ Linux 示例使用与我的其他答案相同的信号处理程序，并演示了如何使用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 5

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

Answer 6

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

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

Answer 7

感谢热心的极客让我注意到 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 8

需要注意的是，一旦你生成了一个核心文件，你就需要使用 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 9

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

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

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

Answer 10

看起来在最后一个 c++ boost 版本中出现了一个库来提供你想要的东西，可能代码是多平台的。 它是boost::stacktrace ，您可以像在 boost sample 中一样使用它：

#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 11

镇上的新国王已经到来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 12

我一直在研究这个问题一段时间。

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

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

谈 libunwind

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

很想听听这个图书馆的意见。

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

Answer 13

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

Answer 14

忘记更改您的来源并使用 backtrace() 函数或宏进行一些黑客攻击 - 这些只是糟糕的解决方案。

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

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

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

Answer 15

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

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

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

Answer 16

win：StackWalk64怎么样http://msdn.microsoft.com/en-us/library/ms680650.aspx

Answer 17

ulimit -c unlimited

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

问候

Answer 18

作为仅限 Windows 的解决方案，您可以使用Windows 错误报告获得等效的堆栈跟踪（包含更多信息）。 只需几个注册表项，就可以将其设置为收集用户模式转储：

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

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

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

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

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

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

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

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

Answer 19

看着：

男人 3 回溯

和：

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

这些是 GNU 扩展。

Answer 20

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

Answer 21

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

Answer 22

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

Answer 23

我发现@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 24

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

win：从 msdn 检查这个。

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

Answer 25

如果您仍然想像我一样单独使用，您可以链接到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 26

我将使用为Visual Leak Detector中的泄漏内存生成堆栈跟踪的代码。 不过，这只适用于 Win32。

Answer 27

除了上述答案之外，这里还有如何让 Debian Linux OS 生成核心转储

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”杀死它。 如果核心转储成功，您将在分段错误指示后看到“（核心转储）”。

Answer 28

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

Answer 29

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

Answer 30

你可能不会喜欢这个——我只能说它对我有用，而且我有类似但不相同的要求：我正在为 1970 年代类似 Algol 的语言编写一个编译器/转译器，它使用 C 作为它是输出，然后编译 C，因此就用户而言，他们通常不知道涉及 C，因此尽管您可能将其称为转译器，但它实际上是一个使用 C 作为中间代码的编译器。 被编译的语言具有在原始本机编译器中提供良好诊断和完整回溯的历史。 我已经能够找到 gcc 编译器标志和库等，它们允许我捕获原始编译器所做的大部分运行时错误（尽管有一个明显的异常 - 未分配的变量捕获）。 当发生运行时错误（例如算术溢出、除以零、数组索引越界等）时，原始编译器将回溯输出到控制台，列出每个活动过程调用的堆栈帧中的所有变量。 我努力在 C 中获得这种效果，但最终只能用 hack 来描述......当程序被调用时，提供 C“main”的包装器会查看它的 argv，如果有特殊选项不存在，它在 gdb 下重新启动自身，并使用包含 gdb 选项和程序本身的“魔术”选项字符串的更改 argv。 然后，这个重新启动的版本通过在调用用我们语言编写的代码的主块之前恢复原始参数来隐藏用户代码中的这些字符串。 当错误发生时（只要它不是被用户代码显式捕获在程序中的错误），它就会退出到 gdb，它会打印所需的回溯。

启动序列中的关键代码行包括：

  if ((argc >= 1) && (strcmp(origargv[argc-1], "--restarting-under-gdb")) != 0) {
    // initial invocation
    // the "--restarting-under-gdb" option is how the copy running under gdb knows
    // not to start another gdb process.

和

  char *gdb [] = {
    "/usr/bin/gdb", "-q", "-batch", "-nx", "-nh", "-return-child-result",
    "-ex", "run",
    "-ex", "bt full",
    "--args"
  };

原始参数附加到上面的 gdb 选项中。 这应该足以提示您为自己的系统做类似的事情。 我确实查看了其他库支持的回溯选项（例如 libbacktrace、 https ://codingrelic.geekhold.com/2010/09/gcc-function-instrumentation.html 等），但它们只输出过程调用堆栈，而不是本地变量。 但是，如果有人知道任何更清洁的机制可以获得类似的效果，请告诉我们。 这样做的主要缺点是变量以 C 语法打印，而不是用户编写的语言的语法。并且（直到我在每个生成的 C 行上添加合适的#line 指令：-（ ）回溯列出了 C源文件和行号。

G PS 我使用的 gcc 编译选项是：

 GCCOPTS=" -Wall -Wno-return-type -Wno-comment -g -fsanitize=undefined
 -fsanitize-undefined-trap-on-error -fno-sanitize-recover=all -frecord-gcc-switches
 -fsanitize=float-divide-by-zero -fsanitize=float-cast-overflow -ftrapv
 -grecord-gcc-switches -O0 -ggdb3 "

Answer 31

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

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

#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);
    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需要获取 function 名称：

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]

然后我们可以将 pipe 转换为c++filt来 demangle：

./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中的+<addr>数字：

./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 <stacktrace>

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

这将是普遍优越的 C++ stacktrace 选项向前移动，如在 C 或 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

Output on 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 ，而且通常我们对此 AFAIK 无能为力。 使用-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 检查 memory： 当程序具有命令行参数时，如何使用 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-回溯-st/1442665#1442665

Answer 32

我忘记了“apport”的 GNOME 技术，但我对使用它知之甚少。 它用于生成堆栈跟踪和其他诊断以进行处理，并且可以自动归档错误。 这当然值得一试。