Есть измененный код, примера из MSDN, использования функции _set_se_translator, которая позволяет транслировать SE-исключение в C++ исключение. Функция отрабатывает, но printf внутри trans_func получает не верные данные.
Т.к. в этом коде, в функции SEFunc происходит EXCEPTION_ACCESS_VIOLATION в связи с чтением по адресу 0, согласно MSDN в ExceptionInformation[0] должна быть 0, а в ExceptionInformation[1] должен быть адрес 0x0.
На самом деле, получаемые в trans_func данные такие: ExceptionInformation[0]=0, ExceptionInformation[1]=0xFFFFFFFF.
Почему такое происходит и как можно получить реальный адрес чтения/записи приведшего к ошибке ?
Вот код эксперимента:
/* SETRANS.CPP
*/#include <stdio.h>
#include <windows.h>
#include <eh.h>
void SEFunc();
void trans_func( unsigned int, EXCEPTION_POINTERS* );
class SE_Exception
{
private:
unsigned int nSE;
public:
SE_Exception() {}
SE_Exception( unsigned int n ) : nSE( n ) {}
~SE_Exception() {}
unsigned int getSeNumber() { return nSE; }
};
void main( void )
{
try
{
_set_se_translator( trans_func );
SEFunc();
}
catch( SE_Exception e )
{
printf( "Caught a __try exception with SE_Exception.\n" );
}
}
void SEFunc()
{
__try
{
printf("%c", *(char *) 0x0);
}
__finally
{
printf( "In finally\n" );
}
}
void trans_func( unsigned int u, EXCEPTION_POINTERS* pExp )
{
printf("%X, %X\n",
pExp->ExceptionRecord->ExceptionInformation[0],
pExp->ExceptionRecord->ExceptionInformation[1]);
throw SE_Exception();
}
20.10.03 18:45: Перенесено модератором из 'C/C++' — ПК
И как, интересно, это влияет на SEH исключения в данном случае, когда у нас в основном try блоке нет external C функций и прочего добра, которое добрый компилер считает exception safe, а эксепшен вообще происходит в __try __finale clause, что и есть SEH?
Доброго времени суток.
Вот результат работы этого (точнее, подобного) кода на VC6 sp5:
In trans_func.
0, 0
In finally
Caught a __try exception with SE_Exception.
Так что похоже все ОК. У меня win2k sp4.
Успехов!
C>Есть измененный код, примера из MSDN, использования функции _set_se_translator, которая позволяет транслировать SE-исключение в C++ исключение. Функция отрабатывает, но printf внутри trans_func получает не верные данные. C>Т.к. в этом коде, в функции SEFunc происходит EXCEPTION_ACCESS_VIOLATION в связи с чтением по адресу 0, согласно MSDN в ExceptionInformation[0] должна быть 0, а в ExceptionInformation[1] должен быть адрес 0x0. C>На самом деле, получаемые в trans_func данные такие: ExceptionInformation[0]=0, ExceptionInformation[1]=0xFFFFFFFF.
C>Почему такое происходит и как можно получить реальный адрес чтения/записи приведшего к ошибке ? C>Вот код эксперимента: C>
Здравствуйте, Andrew S, Вы писали:
P>>ЗЫ компилишь с /EHa?
AS>И как, интересно, это влияет на SEH исключения в данном случае, когда у нас в основном try блоке нет external C функций и прочего добра, которое добрый компилер считает exception safe, а эксепшен вообще происходит в __try __finale clause, что и есть SEH?
На SEH исключения думается это действительно не влияет (хотя чем черт не шутит ).
Но в TFM есть следующее
_set_se_translator
...
Use /EHa instead of /EHsc when using _set_se_translator.
Интересно, а почему флаги отличаются?
Кстати, inaccessible data у меня не получается, пробовал писать в RO, один хрен флаг — 1.
Имхо, null pointer это таки inaccessible address...
P>На SEH исключения думается это действительно не влияет (хотя чем черт не шутит ). P>Но в TFM есть следующее P>
P>_set_se_translator
P>...
P>Use /EHa instead of /EHsc when using _set_se_translator.
Странно, но в моем msdn ни слова об этом, а онлайн версия такой функции вообще не находит. Впрочем, VC6 не выбрасывает try catch в данном случае по описанным выше причинам. Так что в данном случае это действительно не важно. Вот если бы в try-catch не было пользовательской функции — тогда да, компилер смог бы предположить, что в данном try-catch С++ исключение произойти не может и выкинуть соотв catch (а вместе с ним и try). Тогда был бы облом в релизе.
P>[]
P>Интересно, а почему флаги отличаются? P>Кстати, inaccessible data у меня не получается, пробовал писать в RO, один хрен флаг — 1. P>Имхо, null pointer это таки inaccessible address...
P>Просвети, pls.
The first element of the array contains a read-write flag that indicates the type of operation that caused the access violation. If this value is zero, the thread attempted to read the inaccessible data. If this value is 1, the thread attempted to write to an inaccessible address.
Так что все верно. А вот почему у Вас под XP показывается, что все время происходит операция записи, я не знаю. Странно.
