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]

Re: Catching access violation exceptions

"Steven Reddie" <smr@essemer.co m.au> wrote in message
news:f93791bd.0 309282133.650da 850@posting.goo gle.com...[color=blue]
> I understand that access violations aren't part of the standard C++
> exception handling support.[/color]

OK.

On Windows, a particular MSVC compiler[color=blue]
> 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?[/color]

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]

Re: Catching access violation exceptions


Steven Reddie wrote:[color=blue]
>
> 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.[/color]

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_except ion<T>() and bool unwinding(T *) can
follow as well.

regards,
alexander.

[Gianni Mariani]

Re: Catching access violation exceptions

Steven Reddie wrote:[color=blue]
> I understand that access violations aren't part of the standard C++
> exception handling support.[/color]

Right.

On Windows, a particular MSVC compiler[color=blue]
> 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.[/color]

No. This is platform dependant.
[color=blue]
>
> I'm wondering about how to best protect an application or library from
> poorly written user-defined callbacks.[/color]

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[color=blue]
> automatically unregister a user-defined callback if it is found to
> cause any exception including access violations.[/color]

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

Does anyone know of[color=blue]
> a platform-independant method for achieving this?
>[/color]

No.

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

[Gianni Mariani]

Re: Catching access violation exceptions

Alexander Terekhov wrote:[color=blue]
> Steven Reddie wrote:
>[color=green]
>>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.[/color]
>
>
> 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_except ion<T>() and bool unwinding(T *) can
> follow as well.[/color]

How would that fix the OP problem ?

[Attila Feher]

Re: Catching access violation exceptions

Alexander Terekhov wrote:
[SNIP][color=blue]
> 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_except ion<T>() and bool unwinding(T *) can
> follow as well.[/color]

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

--
Attila aka WW

[Ron Natalie]

Re: Catching access violation exceptions


"Steven Reddie" <smr@essemer.co m.au> wrote in message news:f93791bd.0 309282133.650da 850@posting.goo gle.com...
[color=blue]
> 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?[/color]

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]

Re: Catching access violation exceptions


Gianni Mariani wrote:[color=blue]
>
> Alexander Terekhov wrote:[color=green]
> > Steven Reddie wrote:
> >[color=darkred]
> >>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.[/color]
> >
> >
> > 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_except ion<T>() and bool unwinding(T *) can
> > follow as well.[/color]
>
> How would that fix the OP problem ?[/color]

Since there will be no catch(...) ["unprotecte d" 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_except ion" base
class (it can even derive from std::exception, as far as I'm concerned).

regards,
alexander.

[Gianni Mariani]

Re: Catching access violation exceptions [OT]

Alexander Terekhov wrote:[color=blue]
> Gianni Mariani wrote:
>[/color]
....[color=blue][color=green]
>>
>>How would that fix the OP problem ?[/color]
>
>
> Since there will be no catch(...) ["unprotecte d" 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_except ion" base
> class (it can even derive from std::exception, as far as I'm concerned).[/color]

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]

Re: Catching access violation exceptions [OT]


Gianni Mariani wrote:
[...][color=blue]
> 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.[/color]

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.
[color=blue]
>
> 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.[/color]

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/groups?selm=3EEB527C.9D72630%40web.de

(Subject: Re: std0X::expected _exception<T>() )

regards,
alexander.

[Christopher Benson-Manica]

[OT] DOS

Mike Wahler <mkwahler@mkwah ler.net> spoke thus:
[color=blue]
> 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.[/color]

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

--
Christopher Benson-Manica | Jumonji giri, for honour.
ataru(at)cybers pace.org |

[Mike Wahler]

Re: [OT] DOS

"Christophe r Benson-Manica" <ataru@nospam.c yberspace.org> wrote in message
news:bla2ja$19a $1@chessie.cirr .com...[color=blue]
> Mike Wahler <mkwahler@mkwah ler.net> spoke thus:
>[color=green]
> > 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.[/color]
>
> I'd be interested to hear more about this phenomenon... If you'd prefer,[/color]
you[color=blue]
> can e-mail me (minus spamtrap, of course).[/color]

'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]

Re: Catching access violation exceptions

Thanks all for the responses.

"Mike Wahler" <mkwahler@mkwah ler.net> wrote in message news:<PYPdb.759 5$RW4.5904@news read4.news.pas. earthlink.net>. ..[color=blue]
> "Steven Reddie" <smr@essemer.co m.au> wrote in message
> news:f93791bd.0 309282133.650da 850@posting.goo gle.com...[color=green]
> > 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?[/color]
>
> How could there be? Do you think all platforms even
> define 'access violation'?[/color]

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.
[color=blue]
> 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?[/color]

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_excep tion types
and throw only the ones that make sense to a particular system.

Regards,

Steven

[Juergen Heinzl]

Re: Catching access violation exceptions

In article <f93791bd.03092 82133.650da850@ posting.google. com>, Steven Reddie wrote:[color=blue]
> 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?[/color]
[-]
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

--
\ Real name : Juergen Heinzl \ no flames /
\ EMail Private : juergen@mananna n.org \ send money instead /

[Pete Becker]

Re: Catching access violation exceptions

Steven Reddie wrote:[color=blue]
>
> Thanks all for the responses.
>
> "Mike Wahler" <mkwahler@mkwah ler.net> wrote in message news:<PYPdb.759 5$RW4.5904@news read4.news.pas. earthlink.net>. ..[color=green]
> > "Steven Reddie" <smr@essemer.co m.au> wrote in message
> > news:f93791bd.0 309282133.650da 850@posting.goo gle.com...[color=darkred]
> > > 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?[/color]
> >
> > How could there be? Do you think all platforms even
> > define 'access violation'?[/color]
>
> 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.[/color]

The only portable way to enter a signal handler is to call raise.
Support for asynchronous signals (such as SIGSEGV) is not required.
[color=blue]
>[color=green]
> > 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?[/color]
>
> 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.[/color]

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?

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)