[LLVMdev] Use of Vectored Exception Handlers for crash recovery

[Zachary Turner]

As part of my effort to replace our hand-rolled mutexes with std::mutex and
std::recursive_mutex, I found that many of the tests were failing on
Windows after doing the replacement.  One of the reasons was due to the use
of a mutex in lib\Support\CrashRecoveryContext.cpp.  If this mutex is an
std::recursive_mutex or std::mutex, tests fail.  If this mutex is a windows
CRITICAL_SECTION, the tests pass.

I *think*, but am not 100% sure, that this is due to an interaction between
MSVC's mutex implementation and the use of vectored exception handling.

There is a comment in this file that says the following:

// On Windows, we can make use of vectored exception handling to
// catch most crashing situations.  Note that this does mean
// we will be alerted of exceptions *before* structured exception
// handling has the opportunity to catch it.  But that isn't likely
// to cause problems because nowhere in the project is SEH being
// used.

However, my understanding is that the handler specified to
AddVectoredExceptionHandler will get called for EVERYTHING.  In particular,
since we install the handler at the front of the list, if some internal
Windows library wrote something like this:

__try {
} except (...) {
  // handle exception
}

Then our handler would get called before the Windows handler.  Furthermore,
we seem to assume inside the handler that it's impossible to reach the
handler unless there was an actual crash scenario.  Is this necessarily
true?

It's worth pointing out that std::[recursive_]mutex on MSVC are implemented
using ConcRT (Microsoft Concurrency Runtime), which is all sorts of crazy
(even has its own user mode scheduler [1]), so I think the user of a
vectored exception handler is not safe with ConcRT.

Any other windows experts have any thoughts into what might be going on
here?

[1] -
http://blogs.msdn.com/b/nativeconcurrency/archive/2009/02/04/concurrency-runtime-and-windows-7.aspx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140530/a4b14547/attachment.html>