From: Wiedmann, J. <joc...@so...> - 2002-04-26 17:44:04
|
Hi, is it possible to catch an access violation trap in C++ code? The std::exception scheme doesn't seem to work, as exception.h is missing. But then, how to do it otherwise? Thanks, Jochen |
From: Oscar F. <of...@wa...> - 2002-04-26 20:54:08
|
"Wiedmann, Jochen" <joc...@so...> writes: > Hi, > > is it possible to catch an access violation trap > in C++ code? Yes. > The std::exception scheme doesn't seem to work, as exception.h is > missing. But then, how to do it otherwise? std::exception has nothing to do with access violations :-) The C++ Standard says nothing about how a program must behave when a pointer goes rogue (Really, it says "undefined behavior" <g>) This test case illustrates how you can convert an access violation (a Seg Fault on Linux parlance) to a well-behaved C++ expception. If anyone knows a better way or are aware of any problem with this approach, I would grateful to hear your comments. BTW, this does not works with gcc 3.0.3 on Cygwin. #include <stdio.h> #include <signal.h> typedef void (*fptr)(int); class A { private: // Just dummy data members int uno; int dos; public: A() : uno(1), dos(2) { printf("Constructor.\n"); } ~A() { printf("Destructor.\n"); } }; extern "C" void Catcher(int *reglist) { signal(SIGSEGV, (fptr)Catcher); printf("Signal SIGSEGV\n"); throw int(0); } int main() { signal(SIGSEGV, (fptr)Catcher); try { A a; // Test if destructor is called. int *plocal = 0; *plocal = 1; // Makes up an AV } catch(...) { printf("Excepcion.\n"); } printf("Terminando.\n"); } -- Oscar |
From: <dan...@ya...> - 2002-04-26 23:54:42
|
--- Oscar Fuentes <of...@wa...> wrote: > "Wiedmann, Jochen" <joc...@so...> writes: > > This test case illustrates how you can convert an access violation (a > Seg Fault on Linux parlance) to a well-behaved C++ expception. If > anyone knows a better way or are aware of any problem with this > approach, I would grateful to hear your comments. > > BTW, this does not works with gcc 3.0.3 on Cygwin. It does work with 3.1 on mingw. Danny > > > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users http://messenger.yahoo.com.au - Yahoo! Messenger - A great way to communicate long-distance for FREE! |
From: Oscar F. <of...@wa...> - 2002-04-27 01:54:32
|
Danny Smith <dan...@ya...> writes: > --- Oscar Fuentes <of...@wa...> wrote: > > > > This test case illustrates how you can convert an access violation (a > > Seg Fault on Linux parlance) to a well-behaved C++ expception. If > > anyone knows a better way or are aware of any problem with this > > approach, I would grateful to hear your comments. > > > > BTW, this does not works with gcc 3.0.3 on Cygwin. > > It does work with 3.1 on mingw. Thanks for the info, Danny. GCC 3.1 looks really promising. There is at least one problem with the 'signal' approach for detecting AV's, division-by-zero, etc. It is not thread safe. In any case, my proposed solution needs to go a long way through testing and investigation before entering into production code. -- Oscar |
From: <dan...@ya...> - 2002-04-27 04:04:01
|
--- Oscar Fuentes <of...@wa...> wrote: > Danny Smith <dan...@ya...> writes: > > > --- Oscar Fuentes <of...@wa...> wrote: > > > > > > This test case illustrates how you can convert an access violation (a > > > Seg Fault on Linux parlance) to a well-behaved C++ expception. If > > > anyone knows a better way or are aware of any problem with this > > > approach, I would grateful to hear your comments. > > > > > > BTW, this does not works with gcc 3.0.3 on Cygwin. > > > > It does work with 3.1 on mingw. > > Thanks for the info, Danny. GCC 3.1 looks really promising. > > There is at least one problem with the 'signal' approach for detecting > AV's, division-by-zero, etc. It is not thread safe. In any case, my > proposed solution needs to go a long way through testing and > investigation before entering into production code. > I haven't played with it and it really is looking at a different issue, but a simple C/C++ exception wrapper was also sent to the GCC list: http://gcc.gnu.org/ml/gcc/2002-04/msg00000.html Danny > -- > Oscar > > > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users http://messenger.yahoo.com.au - Yahoo! Messenger - A great way to communicate long-distance for FREE! |
From: Oscar F. <of...@wa...> - 2002-04-27 05:36:05
|
Danny Smith <dan...@ya...> writes: > --- Oscar Fuentes <of...@wa...> wrote: > Danny Smith > <dan...@ya...> writes: > > > > > --- Oscar Fuentes <of...@wa...> wrote: > > > > > > > > This test case illustrates how you can convert an access violation (a > > > > Seg Fault on Linux parlance) to a well-behaved C++ expception. If > > > > anyone knows a better way or are aware of any problem with this > > > > approach, I would grateful to hear your comments. > > > > > > > > BTW, this does not works with gcc 3.0.3 on Cygwin. > > > > > > It does work with 3.1 on mingw. > > > > Thanks for the info, Danny. GCC 3.1 looks really promising. > > > > There is at least one problem with the 'signal' approach for detecting > > AV's, division-by-zero, etc. It is not thread safe. In any case, my > > proposed solution needs to go a long way through testing and > > investigation before entering into production code. > > > > I haven't played with it and it really is looking at a different issue, but a > simple C/C++ exception wrapper was also sent to the GCC list: > http://gcc.gnu.org/ml/gcc/2002-04/msg00000.html The issue here is not C/C++ interaction, but the state of the "machine" inside the signal catcher function, as they are special cases. Note that 'signal' is as C++-ish as 'printf', that is, pretty ok. However, the question is if throwing exceptions from a signal handler is supported by the implementation. We know that the 'signal' mechanism itself must work ok in a C++ application (see 18.7.5). But in the same paragraph, the standard puts an scary footnote saying "In particular, a signal handler using exception handling is very likely to have problems". They do refer to 'catch' or to 'throw' (or both) ? I suspect that each compiler writer will interpret the phrase at his convenienve <g>. Possibly I will ask in comp.std.c++, or better, in the gcc mailing list, as they are the real authorities for this issue as far as the g++ compiler is concerned <g> Please note (especially Wu Yongwei) that here a specific fix would be ok, as long as we know that it works. A portable solution is not so important, IMHO, as this is a critical issue and is likely to vary among compilers so each combination of compiler and compiler settings will need separate test, as Wu Yongwei proved. BTW, the signal technique _seems_ to work too on Borland 5.5.1 and Comeau (can't remember wich version) using various switches. -- Oscar |