Page MenuHomePhabricator

[libFuzzer] Properly handle exceptions with UnhandledExceptionFilter
ClosedPublic

Authored by mpividori on Feb 2 2017, 10:30 AM.

Details

Summary

I realized we should use SetUnhandledExceptionFilter instead of AddVectoredExceptionHandler.
After reading the documentation again on Structured Exception Handling, I have a better understanding on the exception handling. It is a bit confusing because all the documentation is not in the same place. (from: https://msdn.microsoft.com/en-us/library/windows/desktop/ms679327(v=vs.85).aspx, https://msdn.microsoft.com/en-us/library/windows/desktop/ms681420(v=vs.85).aspx and https://msdn.microsoft.com/en-us/library/windows/desktop/ms680634(v=vs.85).aspx)

This is the order for the Exception Dispatching:

  • If the process is being debugged, the system notifies the debugger.
  • The Vectored Exception Handler is called. ("Vectored handlers are called in the order that they were added, after the debugger gets a first chance notification, but before the system begins unwinding the stack.")
  • The system attempts to locate a frame-based exception handler by searching the stack frames of the thread in which the exception occurred.
  • If no frame-based handler can be found, the UnhandledExceptionFilter filter is called.
  • Default handling based on the exception type.

So, similar to what we do for asan, we should use SetUnhandledExceptionFilter instead of AddVectoredExceptionHandler, so the user's code that is been fuzzed can execute frame-based exception handlers before we catch them . I mean, we want to catch unhandled exceptions, not all the exceptions.

Diff Detail

Repository
rL LLVM

Event Timeline

mpividori created this revision.Feb 2 2017, 10:30 AM
rnk accepted this revision.Feb 2 2017, 10:46 AM

lgtm Yes, we should only be using VEH for shadow memory page faults.

This revision is now accepted and ready to land.Feb 2 2017, 10:46 AM
This revision was automatically updated to reflect the committed changes.