В джаве было удобно обрабатывать любую ошибку с помощью экзепшнов... В си под линухом я так понял нельзя... Можно либо как-то обработать этот 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 на ночь до полного просветления  

abort() гарантирует лишь дамп, закрытие и сброс всех файловых дескрипторов
логика работы приложения может подразумевать некоторые дополнительные действия для корректного освобождения ресурсов, которые через вызов abort() невозможно осуществить
если использовать longjmp(), то мы потеряем часть стека из-за его раскрутки (изменение [ER]SP)
вот тут и нужно использовать сигнальный фрейм, из которого можно получить адрес вершины стека перед выполнением инструкции, которая привела к SIGSEGV

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

который год программирую и не знал о GDB
спасибо за совет     
могу даже + поставить, хочешь?

Разумеется. Не имеет никакого смысла перехватывать SEGV чтобы ТОЛЬКО сделать abort - core файл и так получится, без всяких перехватов 

Для данного сценария использования longjmp не нужет.

Plugin. Может мне не нравится, что кривой плагин к моей программе помрет, захватив с собой и программу   Его SEGV - это его личные дела, мне чужого не надо   

xvr, 

скрипты? ipc? 

где ты видел плагин в виде исполняемого файла, да еще и с поддержкой IPC для удобства работы?   

На счет IPC не уверен, а вот плагины в виде исполняемых файлов существуют. Например, у valgrind.

как плагин взаимодействует с основной программой?

flashplugin у firefox. 

Добавлено через 25 секунд
ipc не видел, это было имхное предположение 

у меня он называется libflashplayer.so   
или у меня не тот плагин?   

Сколько я смотрел похожие темы - почему-то все считают, что "автор" не умеет писать код. Иногда "автор" пишет 50-потоковое приложение, владеющее общими ресурсами, где java работала более корректно - можно было любым try/catch просто спрятать ошибку, и при этом максимум потерять поток, а не все приложение вместе с его данными.

Я видел plug-in'ы которые реализуютс в виде разделяемой библиотеки, и взаимодействуют с основной программой через IPC. называется Oracle Data Catridge's. Сам plug-in работает в отдельном процессе, чтобы сервер БД не завалить

О, значит, есть такие  Вот это я и имел в виду, хотя конкретных примеров не знал 

Это сообщение отредактировал(а) JackYF - 5.3.2008, 18:04

ключевые слова - "разделяемая" и "библиотека"  

Добавлено @ 18:16
Anton Vatchenko, 
оставайся тогда на java   
ибо SIGSEGV - это действительно обычно кривые руки
без обид

Это сообщение отредактировал(а) MAKCim - 5.3.2008, 18:17

Отнюдь.  Обычно создается впечатление, что 'автор' не умеет пользоваться дебагером (а то и вовсе не знает о наличии такого полезного тулза). Ибо если бы он мог, то такие вопросы не задавал бы - ибо то, что он пытается получить, это именно то, для чего были сделанны дебагеры.
В смысле 'затоптать'?   
Это можно сделать и на любом другом языке, на Jave конечно это проще.