Detection of fatal errors
sebastian
Is there any way to perform an action before program's exit, when it
encounter some kind of fatal error?
Namely I'd like to detect a fatal error and dump buffer with logs to a
file in situations like below:
---- example 1 ----
int *a = 0;
*a = 21;
---- example 1 ----
MyClass *a;
a->someFunction();
I've tried many things:
(1)
try {
} catch( ... ) {
dumpBuffer();
}
(2)
std::set_unexpected( dumpBuffer );
std::set_terminate( dumpBuffer );
(3)
atexit( dumpBuffer ); // this is bypassed anyhow...
None of them works.
My platform is Windows XP, program is written using Qt 4.4.0, compiler
is gcc (Mingw) 3.4.5.
Cheers,
Sebastian
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Joshua...@gmail.com
> [ comp.lang.c++.moderated. First time posters: Do this! ]
There is no C++ standard way to recover from dereferencing a null
pointer. Once that happens, the C++ standard says you're on your own.
There are many kinds of fatal errors. Dereferencing a null pointer is
one of them.
My suggestion is to write better code, put in asserts, use less naked
pointers, and a wide variety of other good C++ styles which will make
such code less likely.
Another option is using static time code analyzers to catch a lot of
these problems. You can also use runtime emulators to run your program
and catch problems like this at run time. Some language extensions,
like how Visual Studios 2003 can throw an exception at null pointer
dereferences, but that is implementation specific and not portable.
However, you will always have this problem, and there is no way to fix
all such problems, either at runtime or compile time.
Alex Shulgin
> Hi,
>
> Is there any way to perform an action before program's exit, when it
> encounter some kind of fatal error?
> Namely I'd like to detect a fatal error and dump buffer with logs to a
> file in situations like below:
>
> ---- example 1 ----
> int *a = 0;
> *a = 21;
Not portable, but there's *nix system call `signal'. You can install
a 'Segmentation fault' (SIGSEGV) handler to catch NULL-pointer
dereference.
> ---- example 1 ----
> MyClass *a;
> a->someFunction();
This might generate fatal error (crash) and might not. Most probably,
however, you'll get the same SIGSEGV on *nix-like platforms.
--
Regards,
Alex
ארינדם מוּחרג'י
> On Jul 24, 10:27 pm, sebastian <Sebastian.P...@googlemail.com> wrote:
>
> > Hi,
>
> > Is there any way to perform an action before program's exit, when it
> > encounter some kind of fatal error?
> > Namely I'd like to detect a fatal error and dump buffer with logs to a
> > file in situations like below:
>
> > ---- example 1 ----
> > int *a = 0;
> > *a = 21;
>
> Not portable, but there's *nix system call `signal'. You can install
> a 'Segmentation fault' (SIGSEGV) handler to catch NULL-pointer
> dereference.
Isn't csignal a part of the C++ standard library (on account of
signal.h and the signal function being part of the C Standard
library). The standard guarantees well-defined behaviour as long as
the signal handling function is a POF (Plain-old function) and has C
linkage.
>
> > ---- example 1 ----
> > MyClass *a;
> > a->someFunction();
>
> This might generate fatal error (crash) and might not. Most probably,
> however, you'll get the same SIGSEGV on *nix-like platforms.
>
So you can possibly use the signal handler function to do some level
of cleanup - although there are restrictions on what functions you can
call inside a signal handler.
Cheers,
Arindam
Jiang
> Is there any way to perform an action before program's exit, when it
> encounter some kind of fatal error?
At the language level, sorry, C++ can not do this for you.
To handle such exceptions we need standardized C++ ABI,
which currently is not available. Therefore the only thing
C++ can do is, well, define them as undefined behaviors.
Yes, dereference a null pointer will invoke undefined
behavior in C++.
If you say this is the dark side of the C++, I will agree
with you. But here please do not blame the language itself,
it "was/is/will be" difficult to standardize the ABI for C++,
well, compared with other single-vender-dominated
languages.
>
> None of them works.
Yes, as other undefined behaviors, most of the time they
will not work [ guaranteed by the standard]. :-)
> My platform is Windows XP, program is written using Qt 4.4.0, compiler
> is gcc (Mingw) 3.4.5.
To catch these kinds of OS-specified exceptions, of course we
need OS support.
- Windows: please check SEH (Structured Exception Handling) @
http://msdn.microsoft.com/en-us/library/ms680657(VS.85).aspx
- *nux: please check signal ( chap 10 of APUE ).
However, unfortunately the MingW environment does not
support SEH, IIRC. If this is still true, you need very low level
hacks to get your job done.
P.S.
there was a thread on C++/OS exception handling, check it @
http://groups.google.com/group/comp.lang.c++.moderated/browse_thread/thread/1c473059041347c3/e94c282577e5856a?lnk=st&q=#e94c282577e5856a
HTH
Jiang
Joshua...@gmail.com
> Isn't csignal a part of the C++ standard library (on account of
> signal.h and the signal function being part of the C Standard
> library). The standard guarantees well-defined behaviour as long as
> the signal handling function is a POF (Plain-old function) and has C
> linkage.
I don't think the C++ or C standard specifies that a signal is raised
when you dereference a null pointer, and that's the system specific
part I believe.
Pete Becker
<arindam....@gmail.com> said:
> On Jul 25, 11:03 pm, Alex Shulgin <alex.shul...@gmail.com> wrote:
>> On Jul 24, 10:27 pm, sebastian <Sebastian.P...@googlemail.com> wrote:
>>
>>> Hi,
>>
>>> Is there any way to perform an action before program's exit, when it
>>> encounter some kind of fatal error?
>>> Namely I'd like to detect a fatal error and dump buffer with logs to a
>>> file in situations like below:
>>
>>> ---- example 1 ----
>>> int *a = 0;
>>> *a = 21;
>>
>> Not portable, but there's *nix system call `signal'. You can install
>> a 'Segmentation fault' (SIGSEGV) handler to catch NULL-pointer
>> dereference.
>
> Isn't csignal a part of the C++ standard library (on account of
> signal.h and the signal function being part of the C Standard
> library). The standard guarantees well-defined behaviour as long as
> the signal handling function is a POF (Plain-old function) and has C
> linkage.
Yes, but neither C nor C++ requires that a signal handler respond to a
signal raised by anything other than the raise() function.
--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)