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 11 1449
On Wed, 24 Aug 2005 17:26:46 -0700, Tamas Demjen <td*****@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
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
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
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
"Tamas Demjen" <td*****@yahoo.com> wrote in message
news:O8**************@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/micro...aa89b74adeeeab
Regards,
Will
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 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
On Thu, 25 Aug 2005 09:18:30 -0700, Tamas Demjen <td*****@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
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
"Tamas Demjen" <td*****@yahoo.com> skrev i en meddelelse
news:O8**************@TK2MSFTNGP09.phx.gbl... 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.
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
Tamas Demjen wrote: 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. ;-)
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 This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: dkcpub |
last post by:
I'm very new to Python, but I couldn't find anything in the docs or faq
about this. And I fished around in the IDLE menus but didn't see anything.
Is there a tool that can determine all the...
|
by: Tom Groszko |
last post by:
Given a try catch scenario
try
{ dosomething();
}
catch (...)
{ report some error
}
Is there any way to figure out what exception is being thrown and
|
by: Steven T. Hatton |
last post by:
If I understand correctly, I have no assurance that I can determine the type
of a simple class instance thrown as an exception unless I explicitly catch
it by name. (non-derived classes having no...
|
by: Z D |
last post by:
Hi,
I was wondering what's the point of "finally" is in a try..catch..finally
block?
Isn't it the same to put the code that would be in the "finally" section
right after the try/catch block?...
|
by: Rob Richardson |
last post by:
Greetings!
I am working on an application that targets a Pocket PC running Windows CE
and SQL Server CE. Almost all functions in the application use a Try block
with a Catch block that looks...
|
by: l.woods |
last post by:
I want to set up my CATCH for a specific exception, but I really don't know
which one of the multitude that it is. I am getting the exception now with
Catch ex as Exception
but I want to be...
|
by: Mr Flibble |
last post by:
Are
try
{
//something
}
catch
{
//
}
|
by: tommaso.gastaldi |
last post by:
It would be useful, sometimes, when debugging, to disable
all the try /catch one has in the program (clearly not commenting them
out).
Any info or hint on that?
-tom
|
by: Tony |
last post by:
Well the subject says it all. Do I have to have it if I use classes in C++?
Tony
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
| |