Beta2 can't catch exceptions?

  • Thread starter Thread starter Tamas Demjen
  • Start date Start date
T

Tamas Demjen

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
 
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("!").
Click to expand...

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
 
Tamas said:
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("!")
Click to expand...

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
 
Doug said:
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
Click to expand...

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
 
Tamas said:
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.
Click to expand...

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
 
Tamas Demjen said:
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.
Click to expand...

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...e+author:depalo&rnum=1&hl=en#d8aa89b74adeeeab

Regards,
Will
 
Arnaud said:
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.
Click to expand...

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 said:
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.
Click to expand...

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
 
Thanks a lot for your reply, it's very interesting and is a fundamental
change to what I've experienced during the past decade.
Click to expand...

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.
Click to expand...

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.
Click to expand...

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

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
 
Tamas Demjen said:
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.
Click to expand...

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.
Click to expand...
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.
Click to expand...
My recommendation is that you - if you really, really have to use such
unreliable software components, at least run them in another process.
Tom
Click to expand...

/Peter
 
Tamas said:
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. ;-)
Click to expand...

The coolest thing about how Windows handles access violations are that
it writes dump files. Windows will send them to Microsoft / the developer.
The dump file may be loaded directly in the VC IDE and enables the
developer to debug the application and the cause of the access violation.

Another cool thing is that Windows Vista task manager now has a context
menu "Write dump file". So that the state of a running application
showing errors, but no crashs, may be analyzed in the IDE.

Andre
 
Back
Top