Обработка исключений

[Silver]

Пишу программу на C++ в Linux. Необходимо обрабатывать исключения типа выход за область памяти, причем не падая с сообщением Segmentation Fault. Такое событие удается отловить с помощью сигнала SIGSEGV. Но что делать дальше с приложением чтобы оно восстановило работу? Кто что посоветует? Не жду легких решений, но и ответов типа это не возможно тоже не надо, т.к. все таки это как то делают.

[/dev/random]

Хм... Интересный вопрос, никогда не задумывался... А что, стандартный try-catch его не ловит?

[Silver]

Хм... Интересный вопрос, никогда не задумывался... А что, стандартный try-catch его не ловит?

Увы нет, сам был в шоке

А сделать по любому надо, хоть ядро переписывай, так что сижу штудирую инет. Пока нашел вот что:
http://www.ibm.com/developerworks/linux/li...l-cppexcep.html

[GRS]

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

[Silver]

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

да че там далеко ходить

Код: Выделить всё

int main()
{
       int *ptr(NULL);

       try
       {
             *ptr = 1;
       }
       catch(...)
       {
             cout<< "Exception" << endl;
       }
}

Если в Линуксе его скомпилить, и запустить то приложение рухнет. Тоже самое если на 0 попытаться поделить.

[sergio]

Я первый раз слышу, что исключения не отлавливались.

А что, сегфолты когда-то отлавливались?
Исключения бывают разные. Помимо языковых. Сегфолт - уровня ОС. Деление на ноль - уровня процессора...

[un-defined]

А что мешает отловить SIGSEGV и в его обработчике сделать все что нужно?

[sergio]

А что мешает отловить SIGSEGV и в его обработчике сделать все что нужно?

Отловить-то можно, но вопрос, что делать? Что в данной ситуации можно сделать? Помимо вывода "Segmentation fault" и уничтожения процесса? Вопрос ТС именно в этом и состоял.

[un-defined]

А что мешает отловить SIGSEGV и в его обработчике сделать все что нужно?

Отловить-то можно, но вопрос, что делать? Что в данной ситуации можно сделать? Помимо вывода "Segmentation fault" и уничтожения процесса? Вопрос ТС именно в этом и состоял.

Ну как минимум проигнорировать Или в обработчике вывести что-то вроде "Segfault detected" и приложение не завершать.
Другое дело конечно, что не надо доводить до того, чтобы приложению вообще приходил сигнал SIGSEGV.

[sergio]

А что мешает отловить SIGSEGV и в его обработчике сделать все что нужно?

Отловить-то можно, но вопрос, что делать? Что в данной ситуации можно сделать? Помимо вывода "Segmentation fault" и уничтожения процесса? Вопрос ТС именно в этом и состоял.

Ну как минимум проигнорировать Или в обработчике вывести что-то вроде "Segfault detected" и приложение не завершать.

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

Другое дело конечно, что не надо доводить до того, чтобы приложению вообще приходил сигнал SIGSEGV.

Так вроде по сути языка выходит, что сегфолт это не допустимая исключительная ситуация, а неисправность в программе, крэш. Другие языки рассматривают аналогичное как нормальное исключительное состояние, там будет NPE или DivideByZeroException. Там виртмашина/интерпретатор производит проверку всякий раз за программиста. В си, если вам нужна проверка исходных значений, чему доверять, что проверять, то "это ваши проблемы". Как-то так имхо.

[Silver]

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

Да, вы правы тут как раз и проблема

Так вроде по сути языка выходит, что сегфолт это не допустимая исключительная ситуация, а неисправность в программе, крэш. Другие языки рассматривают аналогичное как нормальное исключительное состояние, там будет NPE или DivideByZeroException. Там виртмашина/интерпретатор производит проверку всякий раз за программиста. В си, если вам нужна проверка исходных значений, чему доверять, что проверять, то "это ваши проблемы". Как-то так имхо.

Надо как то отлавливать на более низком уровне. Вообще я точно знаю что это возможно. Причем на Линуксе. Но вот как конкретно это сделано ХБЗ.

[Alxn1]

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

[un-defined]

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

man sigaction и т.д.
вот еще - http://wiki.linuxformat.ru/index.php/LXF84:Unix_API
ну и вообще - копать в этом направлении

Так вроде по сути языка выходит, что сегфолт это не допустимая исключительная ситуация, а неисправность в программе, крэш. Другие языки рассматривают аналогичное как нормальное исключительное состояние, там будет NPE или DivideByZeroException. Там виртмашина/интерпретатор производит проверку всякий раз за программиста. В си, если вам нужна проверка исходных значений, чему доверять, что проверять, то "это ваши проблемы". Как-то так имхо.

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

Если взяли в качестве языка C (или CPP, в данном случае это непринципиально), то никто не будет за вас обрабатывать низкоуровневые ошибки, хотя бы потому, что, кроме вас, этим заняться некому. Право самостоятельно выстрелить себе в ногу - это ваше неотъемлемое право

[sergio]

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

man sigaction и т.д.
вот еще - http://wiki.linuxformat.ru/index.php/LXF84:Unix_API
ну и вообще - копать в этом направлении

Боюсь, там немного о другом.
Вот у вас программный код в момент Ч пытается залезть по адресу на кудыкину гору и сегфолтится. Ну перехватили вы СИГСЕГВ, и? Программный код должен игнорировать сбой и пытаться записать оставшийся гигабайт побайтно на ту же кудыкину гору, обрабатывая 1024^3 сегфолтов но упорно пися и пися по несуществующему адресу? Или... или что?
Вот тут и собака зарыта: как вы собираетесь связать языковые механизмы с низкоуровневыми обработчиками исключений ОС, и получить приемлимый результат. Тем более в программе на С++, как у автора вопроса.

Так вроде по сути языка выходит, что сегфолт это не допустимая исключительная ситуация, а неисправность в программе, крэш. Другие языки рассматривают аналогичное как нормальное исключительное состояние, там будет NPE или DivideByZeroException. Там виртмашина/интерпретатор производит проверку всякий раз за программиста. В си, если вам нужна проверка исходных значений, чему доверять, что проверять, то "это ваши проблемы". Как-то так имхо.

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

Если взяли в качестве языка C (или CPP, в данном случае это непринципиально), то никто не будет за вас обрабатывать низкоуровневые ошибки, хотя бы потому, что, кроме вас, этим заняться некому. Право самостоятельно выстрелить себе в ногу - это ваше неотъемлемое право

Э... я не понял, зачем вы пересказали мой пост другими словами, но может так стало понятнее.

[OCTAGRAM]

libsigsegv?

[un-defined]

Боюсь, там немного о другом.
Вот у вас программный код в момент Ч пытается залезть по адресу на кудыкину гору и сегфолтится. Ну перехватили вы СИГСЕГВ, и? Программный код должен игнорировать сбой и пытаться записать оставшийся гигабайт побайтно на ту же кудыкину гору, обрабатывая 1024^3 сегфолтов но упорно пися и пися по несуществующему адресу? Или... или что?
Вот тут и собака зарыта: как вы собираетесь связать языковые механизмы с низкоуровневыми обработчиками исключений ОС, и получить приемлимый результат. Тем более в программе на С++, как у автора вопроса.

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

Тут еще надо четко различать исключения, как инструмент языка, и сигналы, как инструмент операционной системы. Соответственно и способы работы с ними - совершенно разные.

Э... я не понял, зачем вы пересказали мой пост другими словами, но может так стало понятнее.

Перепутал адресатов и авторов сообщений. Это бывает

[Electronix]

Есть замечательная книга А. Робачевский - Операционная система Unix.
В ней подоробно описано как отлавливать сигналы и обрабатывать их. Вообщем рекомендую ее почитать. Глава 2, стр. 160. Сам по примерам из книги обработчики сигналов делал, проверено - работает.

[serzh-z]

А что, стандартный try-catch его не ловит?

А с чего бы ему ловить... Это только майкрософтовские версии компилятора имеют собственные расширенные версии try/catch, которые помимо обработки плюсовых исключений, используют ещё и системный SEH, благодаря чему могу ловить аппаратные исключения, такие как SEGV.

[Silver]

Опишу поподробнее для чего мне это надо. Дело в том что я пишу систему исполнения, которая запускает пользовательские программы. Эти программы пишутся на другом языке и компилируются в бинарник. Моя программа загружает их в память и исполняет. Что там написал пользователь моя прога не знает, но упасть от его действий она не должна. Надо как то отловить исключение и ткнуть его носом. Сделать такое 100% можно, вопрос как.

[Skladnoy]

Запускать отдельным процессом - если child умер от SIGSEGV, то туда ему и дорога

PS А sh никак?

[gmorgunov]

Silver
Здравстсвуйте. Вам нужна книга Марк Дж. Рочкинд "Программирование для UNIX".(Второе изд.)(360 сист. вызовов UNIX).
В главах 9.1.5-9.1.8 описана ваша ситуация. Вот цитата:

"Даже, если вы решили полностью отказаться от использования обработчиков сигналов, тем не менее, иногда надо предусмотреть некоторую минимальную их обработку, чтобы избежать завершения приложения по неосторожности со стороны пользователя.
Кроме того , очень непрофессионально просто завершать приложение в аварийном порядке, если ошибка вызвана, например, некоорректным обращением к памяти. В таких случаях гораздо лучше перехватить сигнал, зафиксировать возникшую проблему в файле
журнала и информировать о ней пользователя, чем просто доверить командной оболочке(или чему-либо еще) вывести малоинформативное сообщение "Program aborted - segmentation violation(Программа завершена аврийно - ошибка обращения к памяти).
Таким образом , большинство приложений должно, как минимум, выполнить следующую последовательность действий ... "

Далее описывается вся технология обработки сигналов и главное !!! - Перечень функций, безопасных в контексте обработки асинхроных сигналов. (Ваши 100% оправдались).

Марк Дж. Рочкинд - один из создателей UNIX. Книга выпущена: "Русская Редакция" "БХВ-Петебург" 2005 год.

[Upliner]

Говорят, под FreeBSD работает обычный throw из обработчика сигнала. А под Linux нужен ещё некий stack fixup(наверное ещё платформенно-зависимый)...

[Silver]

Silver
Здравстсвуйте. Вам нужна книга Марк Дж. Рочкинд "Программирование для UNIX".(Второе изд.)(360 сист. вызовов UNIX).
В главах 9.1.5-9.1.8 описана ваша ситуация. Вот цитата:

Далее описывается вся технология обработки сигналов и главное !!! - Перечень функций, безопасных в контексте обработки асинхроных сигналов. (Ваши 100% оправдались).

Марк Дж. Рочкинд - один из создателей UNIX. Книга выпущена: "Русская Редакция" "БХВ-Петебург" 2005 год.

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

[gmorgunov]

Silver
Да, книга качественная. Это справочник с оттестированными примерами (впрочем, как у всех американцев). Для такой книги недорого
всего за ~ 500 (25). http://linuxforum.ru/style_emoticons/default/rolleyes.gif
Другое дело, время доставки. Если уж вы залезли в такие дебри, советую - брать. Правда, вопросы безопастности UNIX систем умалчиваются.(shell---- shell-code----disassembler). Мог бы и упомянуть http://linuxforum.ru/style_emoticons/default/rolleyes.gif.

[Silver]

Silver
Да, книга качественная. Это справочник с оттестированными примерами (впрочем, как у всех американцев). Для такой книги недорого
всего за ~ 500 (25). http://linuxforum.ru/style_emoticons/default/rolleyes.gif
Другое дело, время доставки. Если уж вы залезли в такие дебри, советую - брать. Правда, вопросы безопастности UNIX систем умалчиваются.(shell---- shell-code----disassembler). Мог бы и упомянуть http://linuxforum.ru/style_emoticons/default/rolleyes.gif.

gmorgunov

Спасибо за наводку. Буду разводить контору на бабки. Только пока она придет, уже придется так сделать. Нашел я тут способ. Может в той книге так и делается. Ключевые слова

Код: Выделить всё

sigsetjmp
siglongjmp

[gmorgunov]

Silver
В общем, не совсем, насколько я понимаю. У него идет обработка всех 28 сигналов - SIGHUP, SIGINT,... SIGSEGV...SYGSYS...
Все основано на :
sigset_t set
struct sigaction act

И далее:
act.sa_handler = handler;
...
ec_neg1( sigaction(SYSSEGV, &act, NULL)

И сама static void handler(int signum) { ... }

Будет время - приведу код Рочкинда полностью( 2.5 стр.) Разбирайтесь. Я пока не все понял( у Рочкинда).

[gmorgunov]

[bSilver][b]
Привет. Отправляю код Рочкинда. Дед непрост, однако. У него сама программа на стр. 609, а макросы - на стр. 31. Они (макросы) идут
сквозняком через всю книгу. Этим макросам посвящена целая глава: предистория, код, пояснения. Так что, если будет совсем непонятно - отпишу. Пробовал тестировать один пример из этой книги, проще, конечно. Подставил необх. (методом подбора) include,
заменил все NULL на 0, EXIT_FAILURE на 1 ну и подобные, понятно-интуитивные вещи и все пошло. Т.е. код, безусловно, оттестирован. Рочкинд об этом и в предисловии пишет. Надо только разобраться. Может кто на форуме поможет. Когда набивал - старался, но возможно где-то ошибся.Видел у него #include <errno.h>, попробуйте включить.
Прикреп. файл

[gmorgunov]

Silver
Нашел Универсальный заголовочный файл. Выкинуть из него FREEBSD, SOLARIS, DARWIN, а все относящ. к LINUX оставить.
Еще: где он предлагает написать свой код обработки попробовать, по-простому, goto ec_cleanup_bgn , хуже не будет.

/* Универс. заголовочный файл */
#if defined(FREEBSD) || defined(DARWIN)
#define BSD_DERIVED
#endif

#if !defined(BSD_DERIVED) /* _POSIX_SOURCE налагает чрезмерные ограничения */
#define SUV_SUS2
#include "suvreq.h"
#endif

#ifdef __GNUC__
#define __GNU_SOURCE /* Для максимального соотв. GNU стандарту C99 */
#endif

#include <unistd.h>

#ifndef __cplusplus
#include <stdbool.h> /* Только C99 *?
#endif

#include <sys/types.h>
#include <time.h>
#include <limits.h>
#ifdef SOLARIS
#define _VA_LIST /* заблокировать определения в файле stdio.h */
#endif
#include <stdio.h>
#ifdef SOLARIS
#undef _VA_LIST
#endif
#include <stdarg.h> /* Место для определения _VA_LIST */
#include <stdlib.h>
#include <stddef.h>
#include <string.h>
#include <ctype.h>
#include <errno.h>
#include <fcntl.h>
#include <assert.h>
#include "ec.h" /* Файл описанный выше */

[MiK13]

Исключения бывают разные. Помимо языковых. Сегфолт - уровня ОС. Деление на ноль - уровня процессора...

А разве Сегфолт -- это уровень ОС? По-моему, ОС только настраивает регисты, определяя диапазон виртуальных адресов, по котороым процессор может писать и которые может читать.
А уж если какая-то инструкция обращается по недопустимому адресу, то тут уже сам процессор должен генерировать прерывание, также как и при попытке деления на ноль.

[gmorgunov]

Так и есть, но прерывания перехватываются. Как вам это:
filter.cc

Код: Выделить всё

#include <signal.h>
#include <iostream>
using namespace std;

char enter[10];

void my(int snum)                                      // ф-ия обработчик сигнала
{                                                      // сигнал получен через структуру sigaction act
      cout << "поймал   сигнал N:" << snum << endl;

      cout << "продолжать?    y/n" << endl;
      gets(enter);

      if ( (enter[0]=='y') || (enter[0]=='Y') )
         system("./filter");                           // повторный вызов приложения
      else
         system("/bin/bash");                          // выход из приложения
}

int main()
{
      struct sigaction act;                            //
      sigemptyset (&act.sa_mask);                      //
      act.sa_handler = &my;                            // формирование структуры sigaction act
                                                       //
      act.sa_flags = 0;                                //

      if (sigaction (SIGSEGV, &act, 0) == -1) {        // при получении сигнала SIGSEGV проверка
         cout<<"ошибка sigaction"<<endl;               // готовности отправить сигнал
      }
                                                       // готовы: ждем получения сигнала

      int* ptr = 0x00000000;                           // моделируем ошибку сегментации
      *ptr = 1;                                        // здесь может быть вызов "плохого" приложения

      return 0;
}