Thread: Graceful Crash on Bad Pointer

I've looked up a number of articles and forum posts about detecting bad pointers and other memory violations and it occured to me that a segfault (I assume that the "This program has stopped responding and needs to be closed" provided by Windows is the same thing) is enough of an indicator of a problem.

However, to the end user should a segfault happen and the progam just hang and 'stop responding', it's irritating to have to force it closed and not have the program say anything at all about what the problem was.

Is there a way that I could 'gracefully crash' (e.g., have the program basically say "Ooops, I'm screwed. Here's a stack trace for the dev's." rather than explode inexplicably) that I can implement using Microsoft's compiler? I know that I can do this rather simply using GCC based compilers (http://stackoverflow.com/questions/7...g-gcc-compiler) using signal hooks and plan to implement that code in the Mac/Linux versions of the program but I'm using VC++ for the Windows version.

Is there a similar method for microsoft based compilers?

Originally Posted by leeor_net

Is there a way that I could 'gracefully crash' (e.g., have the program basically say "Ooops, I'm screwed. Here's a stack trace for the dev's." rather than explode inexplicably) that I can implement using Microsoft's compiler?

You'll need to register an exception filter (either SetUnhandledExceptionFilter or AddVectoredExceptionHandler) then use the ContextRecord member of the parameter to start a stack walk with StackWalk64.

Windows reports a program as not responding for a variety of reasons. In the case of a segfault, it immediatly stops with a message "The program needs to be terminated" or something to that effect. If it's not responding because of an infinite loop, it says something like "The program appears to be busy, do you want to terminate it or wait?". So Windows knows when a program segfaults or not it just uses a lot of fluff when telling you so (e.g., for the idiots that don't know their elbow from the power button). But basically, I know when it's blowing up due to a bad pointer (always my fault usually because I did something stupid).

Using a posix emulation layer makes no sense to me -- this is a graphical application and the code that is generated is native Win32 -- e.g., I have no reason to use an emulation layer (not to mention I haven't got a clue how to implement one). I would like to use a microsoft equivalent to the signal() hook function but my good searches haven't turned up anything.

Originally Posted by adeyblue

You'll need to register an exception filter (either SetUnhandledExceptionFilter or AddVectoredExceptionHandler) then use the ContextRecord member of the parameter to start a stack walk with StackWalk64.

This seems like a promising lead. I'll explore this further.

Thank you!

Originally Posted by brewbuck

Smart pointers can't prevent out-of-bounds access, though. They can for the special case of NULL (throwing an exception instead of crashing), but how can they possibly know if some non-NULL pointer value is valid or not?

Not only that, they can't prevent logic errors such as a division by zero (found on of those, whoops), video memory leaks (guilty on that one too) or the wrath of a third-party program (e.g., API with a flaw in it, malicious code, hardware errors, etc.).

I've accept that as a flawed human, I write flawed code. Inevitably there are going to be bugs in any software that I write be it pointer errors, flawed logic, security holes, etc. One thing I've always hated is when a program has bugs that cause a crash and then requires me, the user, to report to the developer what happened.

In this way, I can have the program automatically report errors to me without the user having to get involved. They know that the problem was reported and can even get a report back stating that we've acknowledged a particular problem.

Regardless of how a crash is handled, the fact that it's handled looks a lot better than having the Operating System tell you that the program you were using blew up (e.g., the infamous "This program has performed an illegal operation").

I found a great program called BugTrap (referred by Codeplug) that does all of the things I wanted to do and many more. Going to strip it down as there are a lot of things that I really don't need but it's a great way to catch major exceptions and 'crash gracefully'.

Thanks for everybody's help!

Here's a stack trace for the dev's

You can have your program generate a core dump when it crashes (for post-mortem debugging).

Yes, it's already dumping a stack trace for me which includes the signal that caused the error (this is on Win32). On our Mac/Linux side we're using signal() to register an exception handler that does a stack trace as well and dumps it to a file.

Am I the only one who thinks that the "This program has stopped responding and needs to be closed" is not a seg fault, but a freeze, caused by an infinite loop or some such thing?