Reporting Crashes in IMVU: Structured Exceptions
This post has moved.
Previously, we discussed the implementation of automated reporting of unhandled C++ exceptions. However, if you've ever programmed in C++, you know that C++ exceptions are not the only way your code can fail. In fact, the most common failures probably aren't C++ exceptions at all. You know what I'm referring to: the dreaded access violation (sometimes called segmentation fault).
How do we detect and report access violations? First, let's talk about what an access violation actually is.
Your processor has a mechanism for detecting loads and stores from invalid memory addresses. When this happens, it raises an interrupt, which Windows exposes to the program via Structured Exception Handling (SEH). Matt Pietrek has written an excellent article on how SEH works, including a description of C++ exceptions implemented on top of SEH. The gist is that there is a linked list of stack frames that can possibly handle the exception. When an exception occurs, that list is walked, and if an entry claims it can handle it, it does. Otherwise, if no entry can handle the exception, the program is halted and the familiar crash dialog box is displayed to the user.
OK, so access violations can be detected with SEH. In fact, with the same mechanism, we can detect all other types of structured exceptions, including division by zero and stack overflow. What does the code look like? It's approximately:
bool handle_exception_impl_seh(function f) { __try { // This is the previously-described C++ exception handler. // For various reasons, they need to be in different functions. // C++ exceptions are implemented in terms of SEH, so the C++ // exception handling must be deeper in the call stack than // the structured exception handling. return handle_exception_impl_cpp(f); } // catch all structured exceptions here __except (EXCEPTION_EXECUTE_HANDLER) { PyErr_SetString(PyExc_RuntimeError, "Structured exception in C++ function"); return true; // an error occurred } }
Note the __try and __except keywords. This means we're using structured exception handling, not C++ exception handling. The filter expression in the __except statement evaluates to EXCEPTION_EXECUTE_HANDLER, indicating that we always want to handle structured exceptions. From the filter expression, you can optionally use the GetExceptionCode and GetExceptionInformation intrinsics to access information about the actual error.
Now, if you write some code like:
Object* o = 0; o->method(); // oops!
The error will be converted to a Python exception, and reported with our existing mechanism. Good enough for now! However, there are real problems with this approach. Can you think of them?
Soon, I'll show the full implementation of the structured exception handler.