В джаве было удобно обрабатывать любую ошибку с помощью экзепшнов... В си под линухом я так понял нельзя... Можно либо как-то обработать этот SegFault, либо перед ним (я знаю где он вываливается) вызвать Stack Trace вызывающих функций?

Можно: man signal & sigaction

Только в gdb

нет, не только
GDB - это такая же программа, как и другие

будут проблемы с возобновлением дальнейшей работы программы
обработка SIGSEGV нужна разве что для корректного освобождения ресурсов

Для того, что бы получить Stack Trace нужен порядочный кусок gdb. Я не спорю, что этот кусок можно написать самому, или выдрать из gdb, но получить его (Stack Trace) одним вызовом чего-нибудь из libc не получится.

Я не очень понимаю, какая может быть 'дальнейшая работа' после SEGV   Если у автора темы есть представление о том, что он будет делать после SEGV, то setjmp/longjmp ему помогут  

не помогут, т. к при их использовании потеряем стек

А зачем автору отлавливать ошибку сегментирования, это глупость, все остальные сигналы прекрасно обрабатываются, а если у тебя в программе возникает такая ошибка, то совет один gdb, и внимательность при написании кода 

для освобождения занятых ресурсов и логирования

Это сообщение отредактировал(а) MAKCim - 1.3.2008, 10:03

Мы его уже практически потеряли при SEGV - продолжить исполнение на этом стеке (без плясок с бубном) уже нельзя  
Единственный способ продолжить (IMHO) - разобраться с инструкцией, вызвавшей SEGV, откорректировать ей регистры/память и повторить, или выполнить самому ее семантику без SEGV и продолжить исполнение со следующей инструкции. И почему то мне кажется, что если автор темы в состоянии это сделать, он бы таких вопросов не задавал   
И еще мне кажется, что у него банальные проблемы с отладкой   

отладка отладка и еще раз отладка, ошибку сегментирования ловить не нужно если она возникает, то как минимум надо устранить причину, а не пытаться ее обработать, а для этого есть gdb

xvr, 
я согласен, но setjmp() и longjmp() тут не помогут
если получил управление наш обработчик SIGSEGV, то в сигнальном фрейме были сохранены значения всех регистров, которые они имели до SIGSEGV
так что нужно использовать этот фрейм, а не longjmp()

можно
если управление получил наш обработчик, то со стеком все в порядке

Добавлено через 4 минуты и 33 секунды

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

При вызове обработчика SEGV будет сформирован специальный фрейм на верхушке пользовательского стека. Если теперь вызвать из обработчика SEGV longjmp с фреймом ВНУТРИ текущего пользовательского стека, то весь стек (включая сформированный системой для обработчика SEGV) будет свернут и исполнение продолжено после setjmp. 

А куда он будет возвращать управление? Там по прежнему команда, которая вызвала SEGV, и она его снова вызовет при возврате   Даже если откорректировать ip (а это уже и есть 'пляски с бубном'), что бы пропустить эту команду, то как минимум та часть семантики, которая была связанна с неудавшемся обращением в память обработанна не будет. Если мы предполагаем, что мы ничего не знаем о команде, вызвавшей SEGV, то поведение программы после этого становится явно неправильным   

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

в этом смысле да, адрес возврата будет либо адресом инструкции, которая вызвала исключение, либо адрес функции окружения (если задан флаг SA_RESTORER)
я же имел в виду, что со стеком как с областью адресного пространства будет все в порядке

оно и не требуется (в смысле продолжение работы)
здесь важно освободить все ресурсы и залогировать как можно больше информации
также лучше сохранить дамп стека для последующей отладки
а его мы не сможем получить через longjmp() по вышеназванным причинам 

Разумеется setjmp/longjmp не панацея и требуют определенного протокола при работе с ними для отлова SEGV.
Например, у нас есть plugin, выполненный в виде .so, и мы хотим, что бы падение в процедурах этого plugin'а не приводило к падениям нашего приложения. В таком случае мы можем устанавливать обработчик SEGV и вызывать setjmp перед вызовами процедур из plugin'а, и сбрасывать обработчик после вызовов. В случае получения SEGV ВНУТРИ процедуры plugin'а, мы можем сделать longjmp, после чего матерно обругаться и выгрузить plugin.
Разумеется, одного вызова setjmp в начале программы, а потом переход по longjmp в SEGV не достаточно   
Т.е. стек будет, но сделать с ним ничего нельзя - только смотреть   
Если интересует стек 'как область адресного пространства', то можно сделать abort и потом (post-mortem) изучать полученный core до посинения   Я имел в виду 'стек вызовов', т.е. его 'живую' копию, на которой можно исполняться.

Здесь надо различать, что же мы хотим получить по SEGV - продолжение работы (вариант с setjmp/longjmp) или аварийное завершение, а затем отладку и разбор полетов - в таком случае abort

зачем велосипеды изобретать?
вводить какие-то протоколы, если нужную информацию можно просто получить из сигнального фрейма

в большинстве случаев да (если не надо анализировать соответствующую инструкцию)

вообще, что-то не понятно, о чем мы спорим
я утверждаю, что setjmp()/longjmp() не лучшее решение, если нужно нечто бОльшее, нежели обычное завершение процесса, при получении SIGSEGV
про abort(), пожалуй, соглашусь

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

Собственно об этом и спорим  Вопрос о том, что такое 'нечто бОльшее', тут возможны варианты:

•  Корректно завершить работу приложения, сохранить стек для посмертного разбора полетов в gdb. - Тут setjmp/longjmp не нужны, нужен abort
•  Изолировать сбойный участок приложения (plugin), сохранить стек сбоя для анализа в gdb, отключить участок кода, продолжить исполнение. setjmp/longjmp + функция для сброса core файла (если она есть  ) 
•  Что такое gdb? - man gdb на ночь до полного просветления