Catching access violation exceptions

[Steven Reddie]

I understand that access violations aren't part of the standard C++
exception handling support. On Windows, a particular MSVC compiler
option enables Microsoft's Structured Exception Handling (SEH) in C++
EH so that a catch (...) will catch an access violation. I don't know
if other platforms support something similar.

I'm wondering about how to best protect an application or library from
poorly written user-defined callbacks. It would be nice to be able to
automatically unregister a user-defined callback if it is found to
cause any exception including access violations. Does anyone know of
a platform-independant method for achieving this?

Regards and TIA,

Steven

 

[Mike Wahler]

I understand that access violations aren't part of the standard C++
exception handling support.

OK.

On Windows, a particular MSVC compiler

option enables Microsoft's Structured Exception Handling (SEH) in C++
EH so that a catch (...) will catch an access violation. I don't know
if other platforms support something similar.

I'm wondering about how to best protect an application or library from
poorly written user-defined callbacks. It would be nice to be able to
automatically unregister a user-defined callback if it is found to
cause any exception including access violations. Does anyone know of
a platform-independant method for achieving this?

How could there be? Do you think all platforms even
define 'access violation'?

E.g. remember MS-DOS, where you could poke a stick
anywhere you liked? Sometimes you'd detonate a mine
with the stick, and the OS just 'went away'. No 'access
violation', no error message, nothing.

Do you think those platforms that do define 'access violation'
mean the same thing by that term?

-Mike

 

[Alexander Terekhov]

I understand that access violations aren't part of the standard C++
exception handling support. On Windows, a particular MSVC compiler
option enables Microsoft's Structured Exception Handling (SEH) in C++
EH so that a catch (...) will catch an access violation. I don't know
if other platforms support something similar.

I'm wondering about how to best protect an application or library from
poorly written user-defined callbacks.

Don't use catch(...). Send an email to Abrahams/Sutter/... demanding
a fix for C++ EH. They shall mandate 2-phase EH and amended exception
specs (make ES work without totally silly catch(...)), to begin with.
Things like bool expected_exception<T>() and bool unwinding(T *) can
follow as well.

regards,
alexander.

 

[Gianni Mariani]

I understand that access violations aren't part of the standard C++
exception handling support.

Right.

On Windows, a particular MSVC compiler

option enables Microsoft's Structured Exception Handling (SEH) in C++
EH so that a catch (...) will catch an access violation. I don't know
if other platforms support something similar.

No. This is platform dependant.

I'm wondering about how to best protect an application or library from
poorly written user-defined callbacks.

You can't.

If a process hits an access violation, you have no idea (other than in
some very special circumstances) just how corrupted things are.


It would be nice to be able to

automatically unregister a user-defined callback if it is found to
cause any exception including access violations.

If data structures are in an inconsistant state, you're hosed.

Does anyone know of

a platform-independant method for achieving this?

No.

You could a library to do this but it's not a trivial task.

 

[Gianni Mariani]

Don't use catch(...). Send an email to Abrahams/Sutter/... demanding
a fix for C++ EH. They shall mandate 2-phase EH and amended exception
specs (make ES work without totally silly catch(...)), to begin with.
Things like bool expected_exception<T>() and bool unwinding(T *) can
follow as well.

How would that fix the OP problem ?

 

[Attila Feher]

Alexander Terekhov wrote:
[SNIP]

Don't use catch(...). Send an email to Abrahams/Sutter/... demanding
a fix for C++ EH. They shall mandate 2-phase EH and amended exception
specs (make ES work without totally silly catch(...)), to begin with.
Things like bool expected_exception<T>() and bool unwinding(T *) can
follow as well.

Care to explain? No links allowed, this is a text only newsgroup. ;-) And
please *not* so briefly that noone will understand.

 

[Ron Natalie]

I'm wondering about how to best protect an application or library from
poorly written user-defined callbacks. It would be nice to be able to
automatically unregister a user-defined callback if it is found to
cause any exception including access violations. Does anyone know of
a platform-independant method for achieving this?

No. It can't be. The nature of hardware faults is very implementation
specific. You'll have to investigate it for each platform.

One thing you can tend to do portably is check for obvious errors like
null pointers (even places where they ought not to be possible like the
address of references or the "this" pointer in your member functions that
are called from the outside). While undefined behavior has most certainly
occurred, you can potentially limit it's impact.

 

[Alexander Terekhov]

How would that fix the OP problem ?

Since there will be no catch(...) ["unprotected" via fixed ES] and no
hurting unwinding (due to currently broken ES), it would cause any
*unexpected* exception end up in the std::unexpected() invoked at throw
point. By default, std::unexpected() calls abort(). I forgot to mention
that he should send an email to Sutter demanding "SEH_exception" base
class (it can even derive from std::exception, as far as I'm concerned).

regards,
alexander.

 

[Gianni Mariani]

Gianni Mariani wrote:
....

How would that fix the OP problem ?

Since there will be no catch(...) ["unprotected" via fixed ES] and no
hurting unwinding (due to currently broken ES), it would cause any
*unexpected* exception end up in the std::unexpected() invoked at throw
point. By default, std::unexpected() calls abort(). I forgot to mention
that he should send an email to Sutter demanding "SEH_exception" base
class (it can even derive from std::exception, as far as I'm concerned).

Apart from being off-topic on both the thread AND the NG; I think
exceptions are intended by the standard to be very simplistic.
Remember, these are a replacement of the setjmp/longjmp semantics which
had all kinds of disasters if you didn't know what you were doing.

I think if your application is unable to work correctly with EH as
defined by the standard, then EH may not be the right solution for you.

 

[Alexander Terekhov]

Gianni Mariani wrote:
[...]

Remember, these are a replacement of the setjmp/longjmp semantics which
had all kinds of disasters if you didn't know what you were doing.

On modern systems, setjmp() kinda "injects" a handler and longjmp
simply unwinds and transfers control to it (causing the second
setjmp's return). They call it "forced unwinding". The only problem
with forced unwinding is that it doesn't work nice with... surprise,
surprise... *catch(...)*. The right approach here is to have a known
"jump" exception, of course.

I think if your application is unable to work correctly with EH as
defined by the standard, then EH may not be the right solution for you.

EH as defined by the current standard is pretty much broken and
is nothing but a compromise influenced by "rumors" that <quote>
On other systems, it is architecturally close to impossible not
to invoke the destructors while searching for a handler </quote>
(Pg. 381, TC++PL [my pdf version])

http://groups.google.com/[email protected]
(Subject: Re: std0X::expected_exception<T>())

regards,
alexander.

 

[Christopher Benson-Manica]

E.g. remember MS-DOS, where you could poke a stick
anywhere you liked? Sometimes you'd detonate a mine
with the stick, and the OS just 'went away'. No 'access
violation', no error message, nothing.

I'd be interested to hear more about this phenomenon... If you'd prefer, you
can e-mail me (minus spamtrap, of course).

 

[Mike Wahler]

I'd be interested to hear more about this phenomenon... If you'd prefer, you
can e-mail me (minus spamtrap, of course).

'Quick-n-dirty explanation':

MDSOS is an 'unprotected' operating system, thus does
not monitor and restrict access to memory or peripheral
devices like e.g. Windows does.

You could directly access and/or modify (e.g. from
assembly, C, BASIC, or whatever language), all of
memory space (including the ubiquitous 'interrupt
vectors'), hardware registers, etc.

Sometimes 'convenient' and almost always faster than
making OS calls, but deadly if you do it wrong.

MSDOS doesn't have conditions like 'access violations'
or 'seg faults' etc. and will let you scribble around
anywhere you like inside its internals.

If you want more details, when I get time, I can email
you a more detailed description. Let me know.


-Mike

 

[Steven Reddie]

Thanks all for the responses.

How could there be? Do you think all platforms even
define 'access violation'?

Mike, why is that significant? ANSI C defines a signal() function
that can catch these things. That's the job of the
compiler/libraries, to make system dependencies useable in a system
independent way.

E.g. remember MS-DOS, where you could poke a stick
anywhere you liked? Sometimes you'd detonate a mine
with the stick, and the OS just 'went away'. No 'access
violation', no error message, nothing.

Do you think those platforms that do define 'access violation'
mean the same thing by that term?

Sure, I remember such things, and know that 'access violation' may
mean different things on different platforms, alignment exceptions
will never occur on some platforms, and writing to the wrong address
may not even cause an exception if the address is valid, however such
things are no reason why a platform independent method for catching
platform dependent exceptions with a catch(...) is impossible. I'm
not asking to be able to identify the type of exception, just a way to
catch them so that I can avoid calling the function in future that
caused the exception. However, that said, it would still be possible
to define some accessviolation_exception and alignment_exception types
and throw only the ones that make sense to a particular system.

Regards,

Steven

 

[Juergen Heinzl]

I understand that access violations aren't part of the standard C++
exception handling support. On Windows, a particular MSVC compiler
option enables Microsoft's Structured Exception Handling (SEH) in C++
EH so that a catch (...) will catch an access violation. I don't know
if other platforms support something similar.

I'm wondering about how to best protect an application or library from
poorly written user-defined callbacks. It would be nice to be able to
automatically unregister a user-defined callback if it is found to
cause any exception including access violations. Does anyone know of
a platform-independant method for achieving this?

[-]
No, not really. You can use whatever signal handling is available,
though signals aren't a C++ thing.

So staying off topic of this group for a little bit more IMHO the whole
idea of trying to "fix" anything during runtime here isn't such a great
idea either as a signal may be risen *after* some damage has been already
done and so from there on all bets are off.

Say should your application be some sort of flight control system please
let me leave the plane *NOW*.

Cheers,
Juergen

 

[Pete Becker]

Thanks all for the responses.



Mike, why is that significant? ANSI C defines a signal() function
that can catch these things. That's the job of the
compiler/libraries, to make system dependencies useable in a system
independent way.

The only portable way to enter a signal handler is to call raise.
Support for asynchronous signals (such as SIGSEGV) is not required.

Sure, I remember such things, and know that 'access violation' may
mean different things on different platforms, alignment exceptions
will never occur on some platforms, and writing to the wrong address
may not even cause an exception if the address is valid, however such
things are no reason why a platform independent method for catching
platform dependent exceptions with a catch(...) is impossible.

That's a good example of undefined behavior. If your implementation
supports it, use it. But with the understanding that it isn't something
you can count on.

What more do you think the language definition should say?

 

[Alexander Terekhov]

Pete Becker wrote:
[...]

The only portable way to enter a signal handler is to call raise.
Support for asynchronous signals (such as SIGSEGV) is not required.

If SIGSEGV would really be asynchronous, there would be no point in
raising it at all.

<Forward Inline>

-------- Original Message --------
Newsgroups: gmane.comp.lib.boost.devel
Subject: Re: boost::execution_monitor impl under windows

-----Original Message-----
From: Alexander Terekhov [mailto:[email protected]]
Sent: 26 September 2003 18:23

SEH doesn't "violate" sequence points, AFAIK.

I *think* I've seen it happen - but it has been a while since I've been
spelunking in this technology and it may be that I've either misremembered
or jumped to an incorrect conclusion. But it seems implausible: SEH can
arise from fetch or store which are often resequenced - so this would
restrict the available optimisations.

Raising SEH exception (or signal) is clearly a *side effect* (that
isn't "covered" by the C/C++ standard... unless it comes "on top"
of accessing an object designated by a volatile lvalue or modifying
an object, "calling a library I/O function, or calling a function
that does any of those operations" aside for a moment). As such,
implementations are indeed kinda constrained in what they can do
with respect to reordering of operations that can raise SEH or
synchronous signals (unless they can prove that reordering doesn't
impact "handling")

Anyway, I've never seen any MS documentation that would support this belief.
(And a quick search of MSDN doesn't return any promising hits.) Do you have
a reference?

Nope. But I'd consider it simply "a bug" if they don't do it right.

Yes.

http://www.google.com/groups?th=f98e4fa7052aa25b
(Subject: __attribute__((cleanup(function)) versus try/finally)

http://www.google.com/groups?th=c41b1edf07790c28
(Subject: Exception handling... it's time to fix the standard)

http://www.google.com/groups?th=94e63c7613727eec
(Subject: std0X::expected_exception<T>())

http://www.google.com/groups?th=236c96ebdd0891c3
(Subject: Re: std0X::expected_exception<T>() [repost])

regards,
alexander.