R e: Catching access violation exceptions

From: Steven Reddie (smr_at_essemer.com.au)
Date: 11/14/03 

Date: 13 Nov 2003 22:00:52 -0800

In article <slrnbnj19j.av.juergen@monocerus.manannan.org>, Juergen
Heinzl wrote:
>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

I understand the concern, but being able to do this has a use that
supports your point of view. That is that if I can catch an access
violation when calling a user-provided DLL I know that an error
occured. Even if rebooting the system is the best option I can at
least attempt to disable that DLL from being used the next time. A
simple "reboot on access violation because the system is in an unknown
state" approach would mean that I keep hitting the same problem and
the plane crashes anyway. Also, assuming that an access violation
means that the system must be rebooted immediately may be just as bad
as assuming that no access violation means that the system is okay.
Catching an access violation is only important in this case if a DLL
is dodgy, and if you may have a dodgy DLL isn't best to do all you can
to detect and recover than do nothing at all? Sure, the system may be
in such a state after an access violation that attempting to flag the
DLL as disabled may not succeed, but if the sh*t hits the fan you have
to do the best you can.

Regards,

Steven

Relevant Pages

  • Re: Access Violation using CCriticalSection in DLL
    ... including the declarations of all variables involved ... precisely where does the access violation happen (it doesn't happen "in the DLL", ... When I Load a DLL (That I ... I pass the address of the log program by reference to the DLL. ...
    (microsoft.public.vc.mfc)
  • Re: VerQueryValue() problem
    ... Do you get an access violation? ... > afterwards I query the version information of the DLL and I am running into> the problem, that VerQueryValue() fails on some systems and runs OK on> others for the same DLL. ... > My eMail-address has been changed due to spam. ...
    (microsoft.public.win2000.developer)
  • Re: Sockets in a DLL, access violation
    ... I don't believe it is a multiple thread problem. ... Jon Harris wrote: ... me the access violation, AFX_MANAGE_STATE is being executed. ... Have you added this code to the beginning of all our DLL exported functions? ...
    (microsoft.public.vc.mfc)
  • Re: Sockets in a DLL, access violation
    ... I initially had a problem when I wasn't doing this with assertions ... me the access violation, AFX_MANAGE_STATE is being executed. ... Have you added this code to the beginning of all our DLL exported functions? ... how can I write my sockets code ...
    (microsoft.public.vc.mfc)