Как автоматически генерировать трассировку стека при сбое моей программы

ulimit -c unlimited

- системная переменная, которая позволит создать дамп ядра после сбоя вашего приложения. В этом случае неограниченная сумма. Найдите в том же каталоге файл с именем core. Убедитесь, что вы скомпилировали свой код с включенной отладочной информацией!

С уважением

Некоторые версии libc содержат функции, работающие с трассировкой стека; вы могли бы использовать их:

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

Я помню, как давно использовал libunwind для получения трассировки стека, но он может не поддерживаться на вашей платформе.

Вы не указали свою операционную систему, поэтому затрудняюсь ответить. Если вы используете систему, основанную на gnu libc, вы можете использовать функцию libc backtrace().

GCC также имеет две встроенные функции, которые могут вам помочь, но которые могут быть или не могут быть полностью реализованы в вашей архитектуре, и это __builtin_frame_address и __builtin_return_address. Оба из них хотят немедленного целочисленного уровня (под немедленным, я имею в виду, что это не может быть переменная). Если __builtin_frame_address для данного уровня отличен от нуля, можно безопасно получить адрес возврата того же уровня.

Смотреть на:

человек 3 след

И:

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

Это расширения GNU.

Важно отметить, что после того, как вы сгенерируете файл ядра, вам нужно будет использовать инструмент 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 ...

Надеюсь, это поможет.

Я бы использовал код, который генерирует трассировку стека для утечки памяти в Визуальный детектор утечки. Однако это работает только на Win32.

Я могу помочь с версией для Linux: можно использовать функции backtrace, backtrace_symbols и backtrace_symbols_fd. См. Соответствующие страницы руководства.

* nix: вы можете перехватить SIGSEGV (обычно этот сигнал возникает перед сбоем) и сохранить информацию в файле. (помимо основного файла, который вы можете использовать, например, для отладки с помощью gdb).

победить: Проверьте это из msdn.

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

В Linux / unix / MacOSX используйте файлы ядра (вы можете включить их с помощью ulimit или совместимый системный вызов). В Windows используйте отчеты об ошибках Microsoft (вы можете стать партнером и получить доступ к данным о сбоях вашего приложения).

ulimit -c <value> устанавливает ограничение на размер файла ядра в unix. По умолчанию ограничение на размер основного файла равно 0. Значения ulimit можно увидеть с помощью ulimit -a.

кроме того, если вы запустите свою программу изнутри gdb, она остановит вашу программу из-за «нарушений сегментации» (SIGSEGV, обычно, когда вы обращаетесь к части памяти, которую вы не распределили), или вы можете установить точки останова.

ddd и nemiver - это интерфейсы для gdb, которые значительно упрощают работу с ним новичкам.

Я забыл о технологии "аппорта" в GNOME, но я мало что знаю об ее использовании. Он используется для создания трассировок стека и другой диагностики для обработки и может автоматически регистрировать ошибки. Это, безусловно, стоит проверить.

Для Linux и, я считаю, Mac OS X, если вы используете gcc или любой компилятор, который использует glibc, вы можете использовать функции backtrace () в execinfo.h для печати трассировки стека и корректного выхода при возникновении ошибки сегментации. Документацию можно найти в руководстве по libc.

Вот пример программы, которая устанавливает обработчик SIGSEGV и выводит трассировку стека в stderr при сбое. Здесь функция baz() вызывает segfault, запускающий обработчик:

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

Здесь показаны модуль загрузки, смещение и функция, из которых взят каждый кадр в стеке. Здесь вы можете увидеть обработчик сигналов в верхней части стека, а также функции libc до main в дополнение к main, foo, bar и baz.

См. Средство трассировки стека в ТУЗ (ADAPTIVE Communication Environment). Он уже написан для охвата всех основных платформ (и не только). Библиотека лицензирована в стиле BSD, поэтому вы даже можете скопировать / вставить код, если не хотите использовать ACE.

Возможно, стоит взглянуть на Google Breakpad, кроссплатформенный генератор аварийных дампов и инструменты для обработки дампов.

Некоторое время я занимался этой проблемой.

И похоронен глубоко в README Google Performance Tools

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

говорит о libunwind

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

Хотелось бы услышать мнения об этой библиотеке.

Проблема с -rdynamic в том, что в некоторых случаях он может относительно значительно увеличить размер двоичного файла.

Linux

Хотя использование функций backtrace () в execinfo.h для печати трассировки стека и изящного выхода, когда вы получаете ошибку сегментации, имеет уже было предложено, я не вижу упоминания о тонкостях, необходимых для обеспечения того, чтобы результирующая обратная трассировка указывала на фактическое местоположение ошибки (по крайней мере, для некоторых архитектур - x86 и ARM).

Первые две записи в цепочке кадров стека, когда вы попадаете в обработчик сигнала, содержат адрес возврата внутри обработчика сигнала и один внутри sigaction () в libc. Фрейм стека последней функции, вызванной перед сигналом (который является местоположением неисправности), теряется.

Код

#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

Несмотря на то, что был предоставлен правильный ответ, который описывает, как использовать функцию GNU libc backtrace()¹, и я предоставил мой собственный ответ, который описывает, как обеспечить обратную трассировку от обработчика сигнала, указывающего на фактическое местоположение ошибки ², я не вижу никакого упоминания о разборка Символы C++, выводимые из трассировки.

При получении трассировки из программы C++ вывод может быть запущен через c++filt¹, чтобы распутать символы, или напрямую с помощью abi::__cxa_demangle¹.

• ¹ Linux и OS X _{Note that c++filt and __cxa_demangle are GCC specific}
• ² 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);
}

Это даже проще, чем "man backtrace", есть немного документированная библиотека (специфичная для GNU), распространяемая с glibc как libSegFault.so, которая, как я полагаю, была написана Ульрихом Дреппером для поддержки программы catchsegv (см. "Man catchsegv").

Это дает нам 3 возможности. Вместо запуска «program -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
   

Во всех трех случаях вы получите более четкую обратную трассировку с меньшим объемом оптимизации (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

Вы можете использовать DeathHandler - небольшой класс C++, который делает все за вас, надежно.

Спасибо entiasticgeek за то, что привлекли мое внимание к утилите 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=

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 

В дополнение к приведенным выше ответам, вот как вы заставляете ОС Debian Linux генерировать дамп ядра

1. Создайте папку «coredumps» в домашней папке пользователя.
2. Перейдите в /etc/security/limits.conf. Под линией «» введите «soft core unlimited» и «root soft core unlimited», если включен дамп ядра для root, чтобы предоставить неограниченное пространство для дампов ядра.
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». Если выгрузка ядра прошла успешно, вы увидите «(дамп ядра)» после индикации ошибки сегментации.

Я видел здесь много ответов, выполняющих обработчик сигнала, а затем выход. Это правильный путь, но помните очень важный факт: если вы хотите получить дамп ядра для сгенерированной ошибки, вы не можете вызвать exit(status). Вместо этого позвоните abort()!

Я обнаружил, что решение @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;
} 

Забудьте об изменении ваших источников и сделайте несколько хаков с функцией backtrace () или макросами - это просто плохие решения.

В качестве правильно работающего решения я бы посоветовал:

1. Скомпилируйте свою программу с флагом «-g» для встраивания отладочных символов в двоичный файл (не волнуйтесь, это не повлияет на вашу производительность).
2. В Linux выполните следующую команду: "ulimit -c unlimited" - чтобы система могла делать большие аварийные дампы.
3. Когда ваша программа выйдет из строя, в рабочем каталоге вы увидите файл «core».
4. Выполните следующую команду, чтобы вывести обратную трассировку на стандартный вывод: gdb -batch -ex "backtrace" ./your_program_exe ./core

Это напечатает правильную читаемую трассировку вашей программы в удобочитаемом виде (с именами исходных файлов и номерами строк). Более того, такой подход даст вам возможность автоматизировать вашу систему: иметь короткий скрипт, который проверяет, создал ли процесс дамп ядра, а затем отправляет обратные трассировки по электронной почте разработчикам или регистрирует это в какой-либо системе регистрации.

Новый король в городе прибыл 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);
}

В качестве решения только для Windows вы можете получить эквивалент трассировки стека (с гораздо большим количеством информации), используя Отчеты об ошибках Windows. С помощью всего нескольких записей в реестре его можно настроить на собирать дампы пользовательского режима:

Starting with Windows Server 2008 and Windows Vista with Service Pack 1 (SP1), Windows Error Reporting (WER) can be configured so that full user-mode dumps are collected and stored locally after a user-mode application crashes. [...]

This feature is not enabled by default. Enabling the feature requires administrator privileges. To enable and configure the feature, use the following registry values under the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps key.

Вы можете установить записи реестра из установщика, у которого есть необходимые права.

Создание дампа пользовательского режима имеет следующие преимущества перед генерацией трассировки стека на клиенте:

• Это уже реализовано в системе. Вы можете использовать WER, как описано выше, или вызвать MiniDumpWriteDump самостоятельно, если вам нужен более точный контроль над объемом информации для сброса. (Обязательно вызовите его из другого процесса.)
• Путь более полный, чем трассировка стека. Среди прочего, он может содержать локальные переменные, аргументы функций, стеки для других потоков, загруженные модули и так далее. Количество данных (и, следовательно, размер) можно настраивать.
• Не нужно отправлять отладочные символы. Это не только резко уменьшает размер вашего развертывания, но и затрудняет обратное проектирование вашего приложения.
• В значительной степени не зависит от используемого вами компилятора. Использование WER даже не требует кода. В любом случае, возможность получить базу данных символов (PDB) - это очень, полезный для автономного анализа. Я считаю, что GCC может либо генерировать PDB, либо есть инструменты для преобразования базы данных символов в формат PDB.

Обратите внимание, что WER может быть запущен только в случае сбоя приложения (т. Е. Система завершает процесс из-за необработанного исключения). MiniDumpWriteDump можно вызвать в любое время. Это может быть полезно, если вам нужно сбросить текущее состояние для диагностики других проблем, кроме сбоя.

Обязательно к прочтению, если вы хотите оценить применимость мини-дампов:

• Эффективные минидампы
• Эффективные минидампы (часть 2)

Похоже, что в одной из последних буст-версий C++ появилась библиотека, которая предоставит именно то, что вы хотите, возможно, код будет мультиплатформенным. Это boost :: stacktrace, который вы можете использовать как как в буст-сэмпле:

#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

Пример обратной трассировки, скопированной из увеличить документацию:

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

Если вы все еще хотите действовать в одиночку, как я, вы можете связать с bfd и избегать использования addr2line, как я сделал здесь:

https://github.com/gnif/LookingGlass/blob/master/common/src/crash.linux.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]