Как отловить ошибку сегментации в Linux?

В Linux они тоже могут быть исключениями.

Обычно, когда ваша программа выполняет ошибку сегментации, ей посылается сигнал SIGSEGV. Вы можете настроить свой собственный обработчик для этого сигнала и смягчить последствия. Конечно, вы действительно должны быть уверены, что сможете оправиться от ситуации. В вашем случае, я думаю, вам следует вместо этого отладить свой код.

Вернемся к теме. Недавно я столкнулся с библиотекой (краткое руководство), который преобразует такие сигналы в исключения, поэтому вы можете написать такой код:

try
{
    *(int*) 0 = 0;
}
catch (std::exception& e)
{
    std::cerr << "Exception caught : " << e.what() << std::endl;
}

Но не проверял. Работает на моем компьютере с Gentoo x86-64. Он имеет платформенно-зависимый бэкэнд (заимствованный из java-реализации gcc), поэтому он может работать на многих платформах. Он просто поддерживает x86 и x86-64 из коробки, но вы можете получить бэкэнд из libjava, который находится в исходных кодах gcc.

Вот пример того, как это сделать на C.

#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

void segfault_sigaction(int signal, siginfo_t *si, void *arg)
{
    printf("Caught segfault at address %p\n", si->si_addr);
    exit(0);
}

int main(void)
{
    int *foo = NULL;
    struct sigaction sa;

    memset(&sa, 0, sizeof(struct sigaction));
    sigemptyset(&sa.sa_mask);
    sa.sa_sigaction = segfault_sigaction;
    sa.sa_flags   = SA_SIGINFO;

    sigaction(SIGSEGV, &sa, NULL);

    /* Cause a seg fault */
    *foo = 1;

    return 0;
}

Для переносимости, вероятно, следует использовать std::signal из стандартной библиотеки C ++, но есть много ограничений на то, что может делать обработчик сигналов. К сожалению, невозможно поймать SIGSEGV из программы на C ++ без введения неопределенного поведения, потому что в спецификации сказано:

1. поведение undefined для вызова любой библиотечной функции из обработчика, кроме очень узкого подмножества стандартных библиотечных функций (abort, exit, некоторые атомарные функции, переустановка текущего обработчика сигнала, memcpy, memmove, характеристики типа, std::move, std::forward и еще немного).
2. это неопределенное поведение, если обработчик использует выражение throw.
3. это неопределенное поведение, если обработчик возвращается при обработке SIGFPE, SIGILL, SIGSEGV

Это доказывает, что невозможно поймать SIGSEGV из программы, используя строго стандартный и переносимый C ++. SIGSEGV по-прежнему перехватывается операционной системой и обычно передается родительскому процессу при вызове функции семейства wait.

Вы, вероятно, столкнетесь с такими же проблемами при использовании сигнала POSIX, потому что в 2.4.3 Сигнальные действия:

Поведение процесса не определено после обычного возврата из функции перехвата сигналов для сигналов SIGBUS, SIGFPE, SIGILL или SIGSEGV, которые не были сгенерированы kill(), sigqueue() или raise().

Несколько слов о longjumps. Предполагая, что мы используем сигналы POSIX, использование longjump для имитации раскрутки стека не поможет:

Хотя longjmp() является асинхронно-сигнально-безопасной функцией, если она вызывается из обработчика сигнала, который прервал не-асинхронную-сигнально-безопасную функцию или эквивалент (например, обработка, эквивалентная exit(), выполненная после возврата из первоначального вызова к main() ), поведение любого последующего вызова не-асинхронно-сигнально-безопасной функции или ее эквивалента не определено.

Это означает, что продолжение, вызванное вызовом longjump, не может надежно вызвать обычно полезную библиотечную функцию, такую ​​как printf, malloc или exit, или вернуться из main, не вызывая неопределенного поведения. Таким образом, продолжение может выполнять только ограниченные операции и может выходить только через какой-то ненормальный механизм завершения.

Короче говоря, перехватить SIGSEGV и возобновить выполнение программы на портативном компьютере, вероятно, невозможно без введения UB. Даже если вы работаете на платформе Windows, для которой у вас есть доступ к структурированной обработке исключений, стоит упомянуть, что MSDN предлагает никогда не пытаться обрабатывать аппаратные исключения: Аппаратные исключения.

И наконец, что не менее важно, возникнет ли какой-либо SIGSEGV при разыменовании указателя с нулевым значением (или указателя с недопустимым значением), это не является требованием стандарта. Поскольку косвенное обращение через указатель с нулевым значением или любой указатель с недопустимым значением является неопределенным поведением < / strong>, что означает, что компилятор предполагает, что ваш код никогда не попытается сделать это во время выполнения, компилятор может произвести преобразование кода, которое исключит такое неопределенное поведение. Например, из cppreference,

int foo(int* p) {
    int x = *p;
    if(!p)
        return x; // Either UB above or this branch is never taken
    else
        return 0;
}
 
int main() {
    int* p = nullptr;
    std::cout << foo(p);
}