необходимо разобраться с обработкой системных исключений , (что писать сюда: catch (...))? компилятор g++

Цитата повстанец @ 02.12.11, 22:50

throw std::exception();

? Ты путаешь обработку исключений С++ и SEH.

Нет, я их разделяю.
Я знаю, что в конечном итоге, как любая из высокоуровневых функций сводится к вызову API-функции, так любое из исклбючений сводится к генерации одного из 22-х исключений (столько у меня в windows.h)

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

Тут ведь как, вот код:

        throw std::exception();
        getchar ();

либо срабатывает обработчик, либо следующая за throw std::exception(); инструкция. Третьего не дано. Ты ведь знаешь, в ассемблерном коде всё последовательно идут инструкция за инструкцией и относительно любой из инструкций можно утвержать:

1)она либо генерит системное исключение
2)либо нет.

Третьего не дано. И если не генерит, значит продолжает программу в неаварийном режиме. А теперь: ни одна из ассемлерных инструкций не вызвала системного исключения. Значит что? Или существуют какие-то икс-системные исключения (но всё же именно системные), коль скоро мы говорим об инструкциях ассемблера, для которых существует свой тайный обработчик, скрытый от всех глаз?

Если я не прав, хотелось бы конкретики, а не общих слов, типа ты не прав потому, что ты не прав. Я и сам вижу, что сообщения не перехватываются.

Сообщения были разделены в тему "SEH и <signal.h> как технология"

Сообщение отредактировано: повстанец - 02.12.11, 23:40

Короче, дела обстоят так. Последним СУЩЕСТВЕННЫМ вопросом в этой теме было обсуждение неработоспособности установщика обработчика системных исключений и самого обработчика соответственно при такой генерации исключений:

throw std::exception();

Я исследовал, что происходит при генерации этого исключения и почему не срабатывает встроенный обработчик.
Так вот, исключение КАК ТАКОВОЕ не генерится. То есть абсолютно.

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

Мне могут возразить: а не обстоят ли дела так, что: системное исключение всё же ГЕНЕРИТСЯ-> управление передаётся на цепочку SEH-обработчиков-> один из которых начинает выводить надписи, а потом вызывает abort()?

Нет, дела так не обстоят. Попробуем, это доказать, Предположим, код

throw std::exception();

генирит системное исключение. Что тогда? А тогда:
Windows решает, хочет ли он послать это исключение обработчику исключений программы. Если это так, и если программа отлаживается, Windows уведомит отладчик о возникновении исключения, приостанавливая программу и посылая EXCEPTION_DEBUG_EVENT (значение 1h) отладчику (это первое предупреждение);

Нам остаётся только запустить прогу с этим исключением и посмотреть, чем дело кончится- прога просто завершится по abort(), а если бы сгенерилось системное исключение, то она на соответствующей инструкции ассемблера споткнулась.

Сообщение отредактировано: повстанец - 03.12.11, 08:56

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

niXman, пока я не узнаю, как из моего последнего поста родились твои вопросы, я воздержусь от ответов. А то мало ли что тебе в голову придёт спросить...

Сообщение отредактировано: повстанец - 03.12.11, 09:19

Цитата niXman @ 03.12.11, 09:02

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

Бажит повстанец, потому что не читает ни MSDN, ни то, что ему пишут (тему правда уже почикали).
UnhandledExceptionFilter НЕ ЛОВИТ ИСКЛЮЧЕНИЯ ЯЗЫКА, она ловит только системные исключения.
Это было написано предыдущим постом, перед тем как я код запостил.

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

#define _WIN32_WINNT 0x0500
 
#include<stdio.h>
#include<windows.h>
 
LONG CALLBACK myVectoredHandler(EXCEPTION_POINTERS *ExceptionInfo)
{
    printf("Exception %08X at %08X\n",
            ExceptionInfo->ExceptionRecord->ExceptionCode,
            ExceptionInfo->ExceptionRecord->ExceptionAddress );
    return EXCEPTION_CONTINUE_SEARCH;
}
 
int main(void)
{
    void *handler=AddVectoredExceptionHandler(1, myVectoredHandler);
    if(!handler)
    {
        printf("Can not register Vectored Exception Handler!\n");
        return -1;
    }
    printf("Generating Exception...\n");
    throw 0;
    printf("Done!\n");
    RemoveVectoredExceptionHandler(handler);
    return 0;
}

Цитата cppasm @ 03.12.11, 11:17

Бажит повстанец

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

Цитата cppasm @ 03.12.11, 11:17

UnhandledExceptionFilter НЕ ЛОВИТ ИСКЛЮЧЕНИЯ ЯЗЫКА, она ловит только системные исключения.
Это было написано предыдущим постом, перед тем как я код запостил.

Я считал, что всякое исключение языка С++ в конечном счёте генерит системное исключение. Ты вот знал, что это не так, а я нет. И веришь, нет, это надо было сказать дословно, ибо из утверждения, что

"SetUnhandledExceptionFilter НЕ ЛОВИТ ИСКЛЮЧЕНИЯ ЯЗЫКА, она ловит только системные исключения."
я не делаю вывод, что исключение языка С++ не генерит системных исключений. Я этого просто не понимаю.

Но здесь мне пришло время делать самому. И я сам всё понял и подробно всё описал в посту номер 50. Заметь, я не клянчил ни у тебя ни у кого бы то ни было чего-нибудь. Я сам разобрался.

Вот этот ключевой вопрос:
"SetUnhandledExceptionFilter НЕ ЛОВИТ ИСКЛЮЧЕНИЯ ЯЗЫКА, она ловит только системные исключения." до меня дошёл через руки. Я больше никого ни о чём не спрашивал. Чё тебе надо? Да, ты программист лучше чем я. Доволен? И больше не беспокойся никогда, лучше я с дураком потеряю, чем с тобой найду.

повстанец, злой ты.

niXman, ты давай по существу говори из чего такие вопросы возникли:
"что, система бажит? или поведение каких-то вендовых функций не соответствует описанию?", как ты воздух сотрясать умеешь, я уже увидел.

Я допёр, наконец, кажись.
gcc использует собственный механизм C++EH. Весь его движок реализован посредством RTL. Что является грубой ошибкой на платформе WinAPI, ибо ни ОС ничего не знает о проходящих C++-исключениях и тем самым не сможет по дороге вызывать __finally, даже если ты, повстанец, и реализуешь их аналоги своими силами, ни программа ничего не знает о возникающих системых исключениях и тем самым не сможет по дороге вызывать деструкторы объектов. Та же проблема будет у gcc и под OS/2, стопудово.
Все компиляторы, поддерживающие SEH, реализуют C++EH через некий специальный ExceptionCode системного исключения. Из предыдущих постов видно, что он равен 0xE06D7363, что, впрочем, недомунтировано. throw реализуется через RaiseException(), где параметрами идёт typeid() от типа исключения и его значение (или ссылка), catch реализуется через __except() с выражением, фильтрующим пришедший тип исключения по RTTI, размотка стека выполняется ОСью через RtlUnwind() и аналогичные, деструкторы размещаются в блоках __finally. Примерно так, очень упрощённо, конечно.
повстанец, забудь о gcc под Win. По крайней мере про эту свою сборку.

Добавлено 03.12.11, 12:13
cppasm, UnhandledExceptionFilter() должен ловить все не перехваченные исключения. Это видно по прежним постам.

Цитата Qraizer @ 03.12.11, 12:12

забудь о gcc под Win

Звучит как приговор. Ты уж извини, я не понял ничё. RTL там, всё такое... Но щас у меня очень даже неплохо сигнализироуется о переполнениии стека.

Приговор, приговор. Если обе технологии не дружат друг с другом, значит ты будешь отгребать попеременно от обоих.

Qraizer, покажи код который как-то ни так работает на мингве, и "так" на "правильном" компиляторе. чтоб было о чем с девелоперами общаться.

Qraizer, а давай по простому? Смотри, реализация C++ исключений В g++ компиляторе, как я понял суть те же самые условные-безусловные переходы, только в другой форме. Так, а теперь, если вдруг возникают системны исключения (В ЛЮБОМ МЕСТЕ ПРОГРАММЫ), они обрабатываются осью самым простым и безхитростным способом- включается отладчик ну или программа просто заканчивается. Тут я не вижу никакого пересечения интересов- просто осью смотрится регистр fs, ищется и берётся первый элемент связном списке (случай, когда меняем связный список пока не рассматриваем), а в этом элементе адрес функции X, которая и вызывает отладчик или что там по сценарию.

Наконец, добавляем сюда SetUnhandledExceptionFilter и смотрим, какое зло она может нам привнести. Ну какое... Опять же при возникновении C++ исключений, её действие пройдёт незамеченным. Если возникнет системное исключение (В ЛЮБОМ МЕСТЕ), то опять же, ось смотрит в регистр fs, находит там адрес первого и единственного элемента в связном списке, и через него адрес знакомой уже нам вызываемой функции X. Вызывается эта функция и из неё недр каким-то хитрым способом вызывается обработчик исключений, который мы установили.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Можно в это всё благолепие внести ещё создание цепочки SEH-обработчиков, но пока обойдёмся, с ними я не разобрался ещё.

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

Сообщение отредактировано: повстанец - 03.12.11, 13:16