f



Catching access violation exceptions

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
0
smr (7)
9/29/2003 5:33:25 AM
comp.lang.c++ 49423 articles. 7 followers. Post Follow

15 Replies
546 Views

Similar Articles

[PageSpeed] 42

"Steven Reddie" <smr@essemer.com.au> wrote in message
news:f93791bd.0309282133.650da850@posting.google.com...
> 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


0
mkwahler (3821)
9/29/2003 6:05:35 AM
Steven Reddie wrote:
> 
> 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.
0
terekhov (1920)
9/29/2003 8:00:21 AM
Steven Reddie wrote:
> 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.

0
gi2nospam (1236)
9/29/2003 1:00:37 PM
Alexander Terekhov wrote:
> Steven Reddie wrote:
> 
>>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.

How would that fix the OP problem ?

0
gi2nospam (1236)
9/29/2003 1:47:21 PM
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.

--
Attila aka WW


0
attila.feher (450)
9/29/2003 1:50:05 PM
"Steven Reddie" <smr@essemer.com.au> wrote in message news:f93791bd.0309282133.650da850@posting.google.com...

> 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.


0
ron156 (1433)
9/29/2003 2:18:40 PM
Gianni Mariani wrote:
> 
> Alexander Terekhov wrote:
> > Steven Reddie wrote:
> >
> >>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.
> 
> 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.
0
terekhov (1920)
9/29/2003 2:23:32 PM
Alexander Terekhov wrote:
> 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.






0
gi2nospam (1236)
9/29/2003 2:38:21 PM
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/groups?selm=3EEB527C.9D72630%40web.de
(Subject: Re: std0X::expected_exception<T>())

regards,
alexander.
0
terekhov (1920)
9/29/2003 2:54:02 PM
Mike Wahler <mkwahler@mkwahler.net> spoke thus:

> 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).

-- 
Christopher Benson-Manica      | Jumonji giri, for honour.
ataru(at)cyberspace.org        |
0
ataru (1609)
9/29/2003 7:53:14 PM
"Christopher Benson-Manica" <ataru@nospam.cyberspace.org> wrote in message
news:bla2ja$19a$1@chessie.cirr.com...
> Mike Wahler <mkwahler@mkwahler.net> spoke thus:
>
> > 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).

'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


0
mkwahler (3821)
9/29/2003 8:21:52 PM
Thanks all for the responses.

"Mike Wahler" <mkwahler@mkwahler.net> wrote in message news:<PYPdb.7595$RW4.5904@newsread4.news.pas.earthlink.net>...
> "Steven Reddie" <smr@essemer.com.au> wrote in message
> news:f93791bd.0309282133.650da850@posting.google.com...
> > 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'?

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
0
smr (7)
9/30/2003 1:00:06 PM
In article <f93791bd.0309282133.650da850@posting.google.com>, Steven Reddie wrote:
> 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

-- 
\ Real name     : Juergen Heinzl       \       no flames      /
 \ EMail Private : juergen@manannan.org \ send money instead /
0
juergen14 (24)
9/30/2003 1:29:25 PM
Steven Reddie wrote:
> 
> Thanks all for the responses.
> 
> "Mike Wahler" <mkwahler@mkwahler.net> wrote in message news:<PYPdb.7595$RW4.5904@newsread4.news.pas.earthlink.net>...
> > "Steven Reddie" <smr@essemer.com.au> wrote in message
> > news:f93791bd.0309282133.650da850@posting.google.com...
> > > 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'?
> 
> 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.

> 
> > 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.

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)
0
petebecker (1324)
9/30/2003 2:13:33 PM
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

Alan.Griffiths@barclayscapital.com wrote:
> 
> > -----Original Message-----
> > From: Alexander Terekhov [mailto:terekhov@web.de]
> > 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.

> 
> > > What advantage does that bring?
> >
> > Long story. Sorry. I can drop some links. Interested?
> 
> 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.

--
http://www.sco.com/ibmlawsuit/ibmamendedcounterclaims.pdf
0
terekhov (1920)
9/30/2003 2:23:41 PM
Reply: