VC++ - Beta2 can't catch exceptions?

Author

Beta2 can't catch exceptions?

Tamas Demjen

2005-08-24, 9:57 pm

I was shocked to learn that VC++ 2005 Beta 2 can't catch Access
Violation exceptions in unmanaged code.

To reproduce this, I created a minimal Win32 console application:

#include "stdafx.h"

int _tmain(int argc, _TCHAR* argv[])
{
int* p = 0;
try
{
*p = 0;
}
catch(...)
{
}
return 0;
}

When I compile and run this with VC++ 2003 or a Borland compiler, the
exception is caught silently as expected. With VC++ 2005 Beta 2, I get
the system dialog "X.exe has encountered a problem and needs to close.
[...] Debug / Send Error Report / Don't Send". Just like if the catch
block wasn't even there. It can't catch divide by zero either.

Am I missing something? C++ exception handling is turned on, and
catch(...) catches other C++ exceptions that I throw, such as throw
std::exception("!").

Tom

Doug Harrison [MVP]

2005-08-24, 9:57 pm

On Wed, 24 Aug 2005 17:26:46 -0700, Tamas Demjen <tdemjen@yahoo.com> wrote:

>I was shocked to learn that VC++ 2005 Beta 2 can't catch Access
>Violation exceptions in unmanaged code.
>
>To reproduce this, I created a minimal Win32 console application:
>
>#include "stdafx.h"
>
>int _tmain(int argc, _TCHAR* argv[])
>{
> int* p = 0;
> try
> {
> *p = 0;
> }
> catch(...)
> {
> }
> return 0;
>}
>
>When I compile and run this with VC++ 2003 or a Borland compiler, the
>exception is caught silently as expected. With VC++ 2005 Beta 2, I get
>the system dialog "X.exe has encountered a problem and needs to close.
>[...] Debug / Send Error Report / Don't Send". Just like if the catch
>block wasn't even there. It can't catch divide by zero either.
>
>Am I missing something? C++ exception handling is turned on, and
>catch(...) catches other C++ exceptions that I throw, such as throw
>std::exception("!").

Access violations aren't C++ exceptions. The short answer is that VC8
finally fixes this bug, and to restore the behavior you're expecting, you
need to specify /EHa instead of /GX or /EHsc. That's actually been required
for several versions now in order to consistently catch untranslated SEs in
catch(...) in release builds. For much more on this, and to understand why
it's generally a bad idea to want to catch SEs in catch(...), see:

http://members.cox.net/doug_web/eh.htm

--
Doug Harrison
VC++ MVP

adebaene@club-internet.fr

2005-08-25, 3:57 am

Tamas Demjen wrote:
> I was shocked to learn that VC++ 2005 Beta 2 can't catch Access
> Violation exceptions in unmanaged code.
>
> To reproduce this, I created a minimal Win32 console application:
>
> #include "stdafx.h"
>
> int _tmain(int argc, _TCHAR* argv[])
> {
> int* p = 0;
> try
> {
> *p = 0;
> }
> catch(...)
> {
> }
> return 0;
> }
>
> When I compile and run this with VC++ 2003 or a Borland compiler, the
> exception is caught silently as expected. With VC++ 2005 Beta 2, I get
> the system dialog "X.exe has encountered a problem and needs to close.
> [...] Debug / Send Error Report / Don't Send". Just like if the catch
> block wasn't even there. It can't catch divide by zero either.
>
> Am I missing something? C++ exception handling is turned on, and
> catch(...) catches other C++ exceptions that I throw, such as throw
> std::exception("!")

To complete what Doug has said, it's a *very* bad idea to try to ignore
silently an Access Violation : An AV is basically a bug in your code
that may put your program in an undetefined state, and trying to
continue to run in those conditions could be dangerous.

That's why it's generally better to let your soft die when an AV is
raised, and do a post-mortem debugging - unless your app is
specifically designed so that different components are really isolated
one from the other and you're certain the AV hasn't corrupted anything.

Arnaud
MVP - VC

Tamas Demjen

2005-08-25, 6:59 pm

Doug Harrison [MVP] wrote:
> Access violations aren't C++ exceptions. The short answer is that VC8
> finally fixes this bug, and to restore the behavior you're expecting, you
> need to specify /EHa instead of /GX or /EHsc. That's actually been required
> for several versions now in order to consistently catch untranslated SEs in
> catch(...) in release builds. For much more on this, and to understand why
> it's generally a bad idea to want to catch SEs in catch(...), see:
>
> http://members.cox.net/doug_web/eh.htm
>
>

Thanks a lot for your reply, it's very interesting and is a fundamental
change to what I've experienced during the past decade.

I see that it can be dangerous, but risking a crash and total data loss
for an insignificant error that 99% of the cases doesn't affect the
program is a bit harsh. For example, a crash in the OCR enigne will
cause all text entities to be lost for a particular page in the *worst*
case. Those errors are caught in the catch and are logged, so there is
warning about it. If it's an application level problem, then maybe items
will be missing from a list box, or similar, but the user will still be
able to save the document before exiting. I don't blindly catch AVs,
without letting the user know about them. Either a dialog box is popped
up, or the error is logged, or both.

Anyway, I understand the concept, it was a very useful feedback. I
appreciate it.

Tom

Arnaud Debaene

2005-08-25, 6:59 pm

Tamas Demjen wrote:

> I see that it can be dangerous, but risking a crash and total data
> loss for an insignificant error that 99% of the cases doesn't affect the
> program is a bit harsh. For example, a crash in the OCR enigne will
> cause all text entities to be lost for a particular page in the
> *worst* case.

No : A rogue pointer writing may do anything to your app : in the *worst*
case, you may corrupt the heap manager, TEB, handle descriptor or any other
vital data structure.

Arnaud
MVP - VC

William DePalo [MVP VC++]

2005-08-25, 6:59 pm

"Tamas Demjen" <tdemjen@yahoo.com> wrote in message
news:O8$WjCZqFHA.2064@TK2MSFTNGP09.phx.gbl...
> I see that it can be dangerous, but risking a crash and total data loss
> for an insignificant error that 99% of the cases doesn't affect the
> program is a bit harsh. For example, a crash in the OCR enigne will cause
> all text entities to be lost for a particular page in the *worst* case.
> Those errors are caught in the catch and are logged, so there is warning
> about it. If it's an application level problem, then maybe items will be
> missing from a list box, or similar, but the user will still be able to
> save the document before exiting. I don't blindly catch AVs, without
> letting the user know about them. Either a dialog box is popped up, or the
> error is logged, or both.

FWIW: Where structured exceptions and C++ are concerned, Doug's essay sums
it up much better than I could. That said, however, in development, or
perhaps in production where you are faced with a pernicious but elusive SE
raised by some component for which you don't have source, you might have a
valid reason to "translate" the SE to a C++ typed exception so that you can
handle it as you describe above.

This thread shows one way to do that:

http://groups.google.com/group/micr...8aa89b74adeeeab

Regards,
Will

Tamas Demjen

2005-08-25, 6:59 pm

Arnaud Debaene wrote:
> No : A rogue pointer writing may do anything to your app : in the *worst*
> case, you may corrupt the heap manager, TEB, handle descriptor or any other
> vital data structure.

I realize the danger, no question about that, that's why I never want a
completely silent handling of AVs. In fact, I want an annoying or scary
message that makes the customer report it to us.

However, I thought a rogue pointer would either cause corruption in the
heap/stack *without* an AV, which remains completely unnoticed until
later in time, or it causes an AV, in which case there is no corruption
whatsoever (the AV itself prevents any corruption). So while an AV is a
sign of programming error that may cause corruption, at the time of the
AV it doesn't.

In my practice, these uncaught exceptions are often either AV due to
NULL pointer dereference, or division by 0 due to unknown resolution
value in an image, or similar programming erros, which often are not
enough for an immediate crash that causes all data to be lost.

I see the danger, and it's a good idea to rethink how we handle access
violations.

Probably the ideal way of handling these errors would be the following:
1. save all data to a recovery file
2. show an error message to the customer that a critical error occured
and the author should be notified
3. exit the application immedaitely
4. the next time the application launches, it recognizes the recovery
data and offers the user for loading/recovering

In an embedded system or mission critical system, maybe log the error,
reboot, and start an auto-recovery.

Tom

Tamas Demjen

2005-08-25, 6:59 pm

Tamas Demjen wrote:

> However, I thought a rogue pointer would either cause corruption in the
> heap/stack *without* an AV, which remains completely unnoticed until
> later in time, or it causes an AV, in which case there is no corruption
> whatsoever (the AV itself prevents any corruption). So while an AV is a
> sign of programming error that may cause corruption, at the time of the
> AV it doesn't.

Actually an AV can be a result of a previously unnoticed stack/heap
corruption, and the memory may already be corrupt at that time. It makes
sense to be cautious...

Tom

Doug Harrison [MVP]

2005-08-25, 6:59 pm

On Thu, 25 Aug 2005 09:18:30 -0700, Tamas Demjen <tdemjen@yahoo.com> wrote:

>Thanks a lot for your reply, it's very interesting and is a fundamental
>change to what I've experienced during the past decade.

Which is literally about as long as I've been trying to get this bug fixed.
:)

>I see that it can be dangerous, but risking a crash and total data loss
>for an insignificant error that 99% of the cases doesn't affect the
>program is a bit harsh. For example, a crash in the OCR enigne will
>cause all text entities to be lost for a particular page in the *worst*
>case. Those errors are caught in the catch and are logged, so there is
>warning about it. If it's an application level problem, then maybe items
>will be missing from a list box, or similar, but the user will still be
>able to save the document before exiting. I don't blindly catch AVs,
>without letting the user know about them. Either a dialog box is popped
>up, or the error is logged, or both.

In that case, I hope you don't overwrite an existing (good) file with the
potentially corrupted data, and I hope you warn the user the file you do
save may contain corrupted data. If you allow the program to continue, you
should also disclose that you have no idea what state it's in, so the user
necessarily proceeds at his own risk and should be prepared to run into
other problems later on that may or may not have anything to do with the
prior bug swallowing event, which, in this day and age, may have opened up
unspeakable security holes.

>Anyway, I understand the concept, it was a very useful feedback. I
>appreciate it.

You're welcome. Many people have resisted the ideas I wrote about far more
vehemently than you. :)

--
Doug Harrison
VC++ MVP

Tamas Demjen

2005-08-25, 6:59 pm

Doug Harrison [MVP] wrote:

> You're welcome. Many people have resisted the ideas I wrote about far more
> vehemently than you. :)

I'm convinced. It made me think for a while, and yes, initially I had
mixed feelings about it. AVs seemed innocent enough in the past, and
customers always took it as serious as a crash, reporting it right away.
I just have no way of knowing how many times I silenced an AV. ;-)

Tom

Peter Koch Larsen

2005-08-25, 6:59 pm

"Tamas Demjen" <tdemjen@yahoo.com> skrev i en meddelelse
news:O8$WjCZqFHA.2064@TK2MSFTNGP09.phx.gbl...
> Doug Harrison [MVP] wrote:
>
> Thanks a lot for your reply, it's very interesting and is a fundamental
> change to what I've experienced during the past decade.
>
> I see that it can be dangerous, but risking a crash and total data loss
> for an insignificant error that 99% of the cases doesn't affect the
> program is a bit harsh.

Do you call dereferencing a null-pointer insignificant?
For example, a crash in the OCR enigne will
> cause all text entities to be lost for a particular page in the *worst*
> case. Those errors are caught in the catch and are logged, so there is
> warning about it.
Well.. if you are using software, that dereferences null pointers, all bets
are off, arent they?

If it's an application level problem, then maybe items
> will be missing from a list box, or similar, but the user will still be
> able to save the document before exiting. I don't blindly catch AVs,
> without letting the user know about them. Either a dialog box is popped
> up, or the error is logged, or both.
>
> Anyway, I understand the concept, it was a very useful feedback. I
> appreciate it.
>
My recommendation is that you - if you really, really have to use such
unreliable software components, at least run them in another process.
> Tom

/Peter

Sponsored Links