<div dir="ltr">It's funny, because now I'm not even sure that's it. Or maybe it was part of it, but not everything. I managed to trigger a test failure even when that mutex was a critical section. I'm reaching the point of deciding that MSVC's mutex implementation is either buggy, or we're doing something that's against the standard. Either way, I'll hammer on it some more before throwing in the towel.</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, May 30, 2014 at 4:02 PM, Reid Kleckner <span dir="ltr"><<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div>I think this functionality mostly exists to support applications that use clang as a library and want to be able to recover from crashes. For example, XCode. Clang's Tooling library also uses this. I don't *think* anyone has been doing this on Windows with any seriousness yet, so I wouldn't be surprised if it isn't robust.</div>
<div><br></div><div>Honestly, it's crash recovery. There's no way it can be robust. We already lost, possibly due to a use-after-free bug. None of this code looks signal safe anyway. =P I'd do the simplest thing that works.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div class="h5">On Fri, May 30, 2014 at 2:34 PM, Zachary Turner <span dir="ltr"><<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr">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.<div>
<br></div><div>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. </div><div><br></div><div>There is a comment in this file that says the following:</div>
<div><br></div><div><div>// On Windows, we can make use of vectored exception handling to</div><div>// catch most crashing situations. Note that this does mean</div><div>// we will be alerted of exceptions *before* structured exception</div>
<div>// handling has the opportunity to catch it. But that isn't likely</div><div>// to cause problems because nowhere in the project is SEH being</div><div>// used.</div></div><div><br></div><div>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:</div>
<div><br></div><div>__try {</div><div>} except (...) {</div><div> // handle exception</div><div>}</div><div><br></div><div>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?</div>
<div><br></div><div>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.</div>
<div><br></div><div>Any other windows experts have any thoughts into what might be going on here? <br></div><div><br></div><div>[1] - <a href="http://blogs.msdn.com/b/nativeconcurrency/archive/2009/02/04/concurrency-runtime-and-windows-7.aspx" target="_blank">http://blogs.msdn.com/b/nativeconcurrency/archive/2009/02/04/concurrency-runtime-and-windows-7.aspx</a><br>
</div></div>
<br></div></div>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></div>