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

Цитата DEADHUNT @ 27.11.11, 16:12

что-то типа такого

ясно.

Это сообщение было перенесено сюда или объединено из темы "GCC-win32 and SEH"

Цитата niXman @ 27.11.11, 15:56

Цитата повстанец @ 27.11.11, 14:28

обработка системных исключений

это еще что такое? оО

смешно... Это когда исключения генерируются системой. Например, при переполнении стека.

Это сообщение было перенесено сюда или объединено из темы "GCC-win32 and SEH"

Цитата повстанец @ 27.11.11, 16:36

Это когда исключения генерируются системой. Например, при переполнении стека.

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

Это сообщение было перенесено сюда или объединено из темы "GCC-win32 and SEH"

гы... а в компиляторе от мелкомягких есть... И вообще, я так понимаю mingw это сборка для винды, так что вот!

Это сообщение было перенесено сюда или объединено из темы "GCC-win32 and SEH"

Сообщение отредактировано: повстанец - 27.11.11, 17:38

Цитата DEADHUNT @ 27.11.11, 16:12

только я не понимаю зачем это нужно.

Для СОМ, к примеру. Из-за того, что одна прога запихнула невалидный адрес, сервер (а за ним и все остальные клиенты) упасть не должен.

Добавлено 27.11.11, 17:13

Цитата niXman @ 27.11.11, 16:46

это какая-то поделка, по всей видимости. в стандарте ничего про это нет.

В стандарте много чего нет. Например там нет ни одного способа связывания с системным API.

Это сообщение было перенесено сюда или объединено из темы "GCC-win32 and SEH"

Если мы говорим о том, что является частью API ОС и что тем не менее Стандарт любезно оставил на усмотрение реализаций, в данном случае это связь системых исключений с C++ Exception Handling, то уповать на Стандартную неопределённость поведения значит заметать мусор под ковёр. Системные исключения в WinAPI присутствуют в виде технологии SEH, и она играет важнейшую роль для 24/7 приложений.

Цитата DEADHUNT @ 27.11.11, 16:44

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

Нормально написанная программа в таком случае не должна использовать никаких библиотек. Даже статических. О динамических, COM- ActiveX- итп-компонентах, и даже просто о плагинной архитектуре можно просто забыть. Да, в таких случаях SEH не нужна, ибо мы сами пишем весь код своего приложения, и вполне способны отвечать за его качество. Но всё равно остаётся процесс разработки и отладки.
niXman, вопрос, как я понимаю, пока не заключается в поддержке SEH, пока вопрос выглядит как "при каких условиях g++ может не поддерживать C++ Exception Handling", ибо транслировать SEH в C++EH можно тем же WinAPI, коль уж портированный под WinAPI компилятор не поддерживает расширения синтаксиса, рекомендованные MS для своих ОСей уже без малого 20 лет.

Это сообщение было перенесено сюда или объединено из темы "GCC-win32 and SEH"

Цитата Повстанець @ 27.11.11, 17:12

Для СОМ, к примеру. Из-за того, что одна прога запихнула невалидный адрес, сервер (а за ним и все остальные клиенты) упасть не должен.

это стандартная ситуация. но я совершенно не понимаю для чего тут SEH...

if ( ptr_type ptr = server->get_iface(...) ) {
   work with ptr if it`s valid
} else {
   throw exception_type(...);
}

Невалидные указатели не обязательно null_ptr. (int*)0x12345678 тоже с большой долей вероятности будет невалидным и вызывать EXCEPTION_ACCCESS_VIOLATION при разыменовании.
За действия не нашего кода мы не можем отвечать, но мы можем защититься от них, поймав фаулт, возникший в плагине, и вырубив такой плагин к чертям, к примеру. SEH для этого - стандартная и очень удобная практика для WinAPI.

Цитата Qraizer @ 28.11.11, 09:06

(int*)0x12345678

ну так это означает что баг в том коде который вернул такой указатель. к чему лечить последствия?
не могу представить здравый код, который возвращал бы случайные указатели. ( (int*)random() )

Сообщение отредактировано: niXman - 28.11.11, 09:31

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

Цитата niXman @ 28.11.11, 09:30

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

Т.е. ты предлагаешь, к примеру, такую ситуацию: в Photoshop закосячил какой-то плагин, вернул не валидный адрес или ещё что, и Photoshop вместо того, чтобы поймать исключение и написать пользователю что плагин глючный, просто тупо упадёт не сохранив работу пользователя.
Что-то мне кажется пользователей такой расклад не порадует.
Ты не можешь отвечать за код, который написан не тобой, и должна быть возможность оградиться от последствий исполнения такого кода.
Собственно это реализуется с помощью WinAPI даже без поддержки SEH на уровне компилятора, так что...

Qraizer, если ты перенесёшь тему в холивар, где же я буду сообщать о том, как я предлагаю работать с исключениями? А я предлагаю.
Вот я провёл тут небольшое исследование. Помнишь, ты попрошал у niXmanа, почему не работает код отсюда (сообщение номер 7)?


Так вот, SetUnhandledExceptionFilter это, оказывается, очень-очень-очень, интересная функция. В самом деле, в случае неудачи, она возвращает ноль, а в случае удачи- код нового обработчика, что и происходит

Но тут почитав кое-что, поспрошав людей, я понял, что она должна внести ещё и изменения в связный список элементов типа EXCEPTION_REGISTRATION_RECORD! А она этого не делает! То есть я вот тут выложил программу, кому интересно запустите, компилятор g++ должен быть. Хе, адрес обработчика после УДАЧНОЙ отработки SetUnhandledExceptionFilter НЕ ИЗМЕНЯЕТСЯ.

Первый раз вижу API-функцию, так половинчато работающую. Предварительный вывод: компилятор g++ в этой части вообще не причём. Имеется задокументированная функция, которая должна установить новый обработчик исключений, которая его якобы устанавливает, но не устанавливает. Это у меня вопрос к майкрософту возник, почему так.
Щас я пытаться буду написать свою реализацию SetUnhandledExceptionFilter

#include <windows.h>
#include <iostream>
#include <stdio.h>
#include <excpt.h>
  
      
      
                                   //+
                                   //+
                                   //+
LONG WINAPI TopLevelUnhandledExceptionFilter(PEXCEPTION_POINTERS x)      {
 //Это функция-обработчик исключений, которая никогда не вызывается
 printf ("hello, word!\n");
 getchar ();
 return 0;
}
            //....................................................
                                   //+
                                   //+
                                   //+
      
int main(){
 
 SetConsoleCP (1251);
 SetConsoleOutputCP (1251);
 
 
 PNT_TIB pTIB;
 PEXCEPTION_HANDLER handler_;
 
 printf ("новая функция-обработчик находится по адресу: %x\n"\
         ,(unsigned int)TopLevelUnhandledExceptionFilter);
 
 
                                 //++
//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 pTIB= (PNT_TIB)NtCurrentTeb();
// //NtCurrentTeb() недокументированная функция,
//суть ассемблерная вставка где-то
 
 //А это сразу указатель найдём на функцию-обрабочик исключения
 handler_= ((PEXCEPTION_REGISTRATION_RECORD)pTIB->ExceptionList)->handler;
 
 
 printf ("\nДо вызова SetUnhandledExceptionFilter:\n");
 printf ("TEB текущего потока== %x\n", (unsigned int)pTIB);
 printf ("TIB текущего потока== %x\n", (unsigned int)pTIB);
 printf ("Стандартная Функция-обработчик исклюючения находится по адресу== %x\n", (unsigned int)handler_);
//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
                                 //++
 
 
//устанавливаем обработчик исключения
printf ("\nSetUnhandledExceptionFilter вернула %x\n\n",\
         (unsigned int)SetUnhandledExceptionFilter(TopLevelUnhandledExceptionFilter));;
 
 
                                 //++
//повторяем процедуру нахождения адреса обраблотчика
//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 pTIB= (PNT_TIB)NtCurrentTeb();
 handler_= ((PEXCEPTION_REGISTRATION_RECORD)pTIB->ExceptionList)->handler;
 printf ("После вызова SetUnhandledExceptionFilter:\n");
 printf ("TEB текущего потока== %x\n", (unsigned int)pTIB);
 printf ("TIB текущего потока== %x\n", (unsigned int)pTIB);
 printf ("Новая Функция-обработчик исклюючения находится по адресу== %x\n", (unsigned int)handler_);
//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
                                 //++
 getchar ();
 return 0;
}

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

Цитата повстанец @ 02.12.11, 21:07

Не ловит, доказательства в моём посту номер 153

Я не знаю что ты там понаписал, у меня ловит:

#include<stdio.h>
#include<windows.h>
 
int *pointer=0;
 
LONG WINAPI myUnhandledExceptionFilter(struct _EXCEPTION_POINTERS *ExceptionInfo)
{
    printf("Exception %08X at %08X\n",
            ExceptionInfo->ExceptionRecord->ExceptionCode,
            ExceptionInfo->ExceptionRecord->ExceptionAddress );
    return EXCEPTION_EXECUTE_HANDLER;
}
 
int main(void)
{
    SetUnhandledExceptionFilter(myUnhandledExceptionFilter);
    printf("Generating Exception...\n");
    *pointer=123;
    printf("Done!\n");
    return 0;
}

>test.exe
Generating Exception...
Exception C0000005 at 0040104F

Добавлено 02.12.11, 21:54

Цитата niXman @ 02.12.11, 20:00

собственно, ЯП выполняемые на ВМ обязаны работать быстрее компилируемых, ибо эвристический анализ.

А как насчёт того, что код VM потом всё равно переводится JIT компилятором в нативный для исполнения? А на это время надо.

Цитата повстанец @ 02.12.11, 14:24

Qraizer, если ты перенесёшь тему в холивар, где же я буду сообщать о том, как я предлагаю работать с исключениями?

Это разговор даже не для С++ Общих. Тут прямая дорога обратно в Системное и WinAPI.

Добавлено 02.12.11, 22:22

!

Дух Повстанца, создание клонов запрещено Правилами. Незачем было доводить ситуацию до критической. Если твой клон стремится во флейм и тут не будет появляться, я не против. Банить или не банить, пусть решают тамошние модеры. Но тут уровень вверх твой.

Сообщение отредактировано: Qraizer - 02.12.11, 22:22

Цитата cppasm @ 02.12.11, 21:50

Я не знаю что ты там понаписал, у меня ловит:

У тебя не ловит

      #include<stdio.h>
      #include<windows.h>
      #include<iostream>
      
      int *pointer=0;
      
      LONG WINAPI myUnhandledExceptionFilter(struct _EXCEPTION_POINTERS *ExceptionInfo)
      {
          printf("Exception %X at %X\n",
                  (unsigned int)ExceptionInfo->ExceptionRecord->ExceptionCode,
                  (unsigned int)ExceptionInfo->ExceptionRecord->ExceptionAddress );
          return EXCEPTION_EXECUTE_HANDLER;
      }
      
      int main(void)
      {
          SetUnhandledExceptionFilter(myUnhandledExceptionFilter);
          printf("Generating Exception...\n");
          throw std::exception();
          printf("Done!\n");
          return 0;
      }

Generating Exception...
terminate called after throwing an instance of 'std::exception'
  what():  std::exception
 
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

компиляторр g++, windows xp