Segmentation fault

Зачем перехватывать "Segmentation fault"?! Это же бред редкостный. Если нужно сохранить какие-то данные/освободить какие-то ресурсы, то единственные способ, который я знаю перехватывать сигнал SIGSEGV и устанавливать свой обработчик.

это не исключение.

man 7 signal
man 2 signal

> The behavior of a process is undefined after it returns normally from a signal-catching function for a SIGBUS, SIGFPE, SIGILL, or SIGSEGV signal that was not generated by kill(), sigqueue(), or raise().

http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_04.html

Спасибо. Не скажете, что тогда перехватывает try { } catch (...) {}

никак. используй сигналы.

Все что из этой же программы или какой-то заюзаной тобой либы генерится посредством throw()
А SIGSEGV это уже удел ядра, его можно перехватить только с помощью обработчиков сигналов, но это я тебе не рекомендую делать, лучше пиши так свои программы, что бы SIGSEGV не было.

исключения c++. Сигналы, уже сказали, удел ядра. Почитай те мануалы, там всё написано.

> Спасибо.

Собирай программу с опциями -O0 -g3, делай ulimit -c unlimited, запускай программу, на образовавшийся core пускай gdb, делай в нём bt full.

> Не скажете, что тогда перехватывает try { } catch (...) {}

Exceptions перехватывает. Часть языка C++.

Ясно. Но иногда никак не удается написать без проблем. К примеру сейчас я нашел потихоньку место где происходит этот fault. Это метод класса, строчка fields.push_back(arr[i]); Причем я выводил на экран arr[i] - все нормально - целое число. Эта беда, причем, появилась когда я добавил к членам класса массив - char buff[30]; Понятия не имею, что происходит.

>>Эта беда, причем, появилась когда я добавил к членам класса массив - char buff[30]; Понятия не имею, что происходит.

все признаки битья памяти налицо. Можно скомпилить с -g и прогнать в valgrind (рекомендую).

> Ясно. Но иногда никак не удается написать без проблем.

Какой смысл пытаться восстановить программу, которая испортила свои данные? Зачем такой программе дальше продолжать работать? Максимум от всех этих заморочек с перехваткой сигналов - это вывод в лог стека вызовов у программы, не доступной для отладки на момент падения, чтобы в дальнейшем иметь представление, откуда начинать копать.

Программа свои данные не портила, а пыталась испортить то, что портить нельзя.

Аналога Win32 SEH в Linux нет?

Пытаться испортить то, чего портить нельзя - признак того что ранее данные уже были испорчены. Продолжение такой программы мало что бессмыслено - даже опасно. Всё что можно сделать: посмотреть состояние текущего стека для отлова места ошибки.

>Программа свои данные не портила, а пыталась испортить то, что портить нельзя.

Программа уже работает не правильно. Имеет смысл продолжать [y/N] ?

С чего это данные должны быть вдруг испорченными? От кода тут зависит все не в меньшей степени.

> С чего это данные должны быть вдруг испорченными?

// == code ==

int array1[10];

int array2[10];

int array3[10];

...

array2[0] = 5;

memset( array1, 33, 20*sizeof(int) );

array3[ array2[0] ] = 123;

// Segmentation fault

// == end of code ==

Вопрос: В каком месте данные были испорчены? И это всего лишь тривиальный пример. В реальности до креша программа может выполнять код достаточно долго прежде чем испорченые данные (на которые мы надеимся что они целые) себя проявят.

К чему я собственно. Segmentation fault - наш друг и брат, он защищает нашу программу от вредоносных действий (-: Бояться не стоит, ему нужно радоваться и петь хвалебные песни.

> Аналога Win32 SEH в Linux нет?
перехват сигналов + setjmp()/longjmp()

> Программа свои данные не портила, а пыталась испортить то, что портить нельзя.

Она просто добралась до hole в vma (вероятно, попутно запоганив свои данные), там портить нечего :)

Вопрос, в каком месте были испорчены данные:

int main()
{ 
  return main ();
}

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