[PATCH] Change llvm::sys::Mutex implementation to use STL-provided mutexes.

[Zachary Turner]

So, the issue is that std::mutex and std::recursive_mutex simply cannot be
used during an atexit() handler.  It still seems like a good drop-in
replacement for the hand-rolled mutex in all other cases.

This is not documented anywhere, but if you dig into the code you'll find
that std::mutex and std::recursive_mutex are implemented using ConcRT
(microsoft concurrency runtime), and it relies on a call to
RegisterWaitForSingleObject().  That function in turn uses QueueUserAPC,
and if you check the documentation you'll see that it says "When the thread
is in the process of being terminated, calling QueueUserAPC to the thread's
APC queue will fail with ERROR_GEN_FAILURE (31)".

So, TL;DR - can't use mutexes from atexit handler.  This seems like a
reasonable restriction, as atexit handlers are probably pretty rare anyway.

I will try to find a way to change the shutdown order to not rely on the
atexit handler.


On Thu, May 29, 2014 at 4:25 PM, Zachary Turner <zturner at google.com> wrote:

> It looks like the issue is that we're trying to acquire the mutex during
> process shutdown.  Specifically, here's a partial callstack:
>
>   libclang.dll!mtx_do_lock(_Mtx_internal_imp_t * * mtx=0x01b118e4, const
> xtime * target=0x00000000) Line 67 C++
>   libclang.dll!_Mtx_lock(_Mtx_internal_imp_t * * mtx=0x01b118e4) Line 153
> C++
>   libclang.dll!std::_Mtx_lockX(_Mtx_internal_imp_t * * _Mtx=0x01b118e4)
> Line 68 C++
>   libclang.dll!std::_Mutex_base::lock() Line 41 C++
>   libclang.dll!llvm::sys::Mutex<0,1>::acquire() Line 94 C++
>   libclang.dll!llvm::MutexGuard::MutexGuard(llvm::sys::MutexBase &
> m={...}) Line 33 C++
> > libclang.dll!cleanupOnDiskMapAtExit() Line 124 C++
>   libclang.dll!doexit(int code=0, int quick=0, int retcaller=1) Line 628 C
>   libclang.dll!_cexit() Line 448 C
>   libclang.dll!_CRT_INIT(void * hDllHandle=0x0f360000, unsigned long
> dwReason=0, void * lpreserved=0x00000001) Line 169 C
>   libclang.dll!__DllMainCRTStartup(void * hDllHandle=0x0f360000, unsigned
> long dwReason=0, void * lpreserved=0x00000001) Line 399 C
>   libclang.dll!_DllMainCRTStartup(void * hDllHandle=0x0f360000, unsigned
> long dwReason=0, void * lpreserved=0x00000001) Line 340 C
>   ntdll.dll!_LdrxCallInitRoutine at 16 () Unknown
>   ntdll.dll!LdrpCallInitRoutine() Unknown
>   ntdll.dll!LdrShutdownProcess() Unknown
>   ntdll.dll!RtlExitUserProcess() Unknown
>
>
> And this is the mutex that is hung.  If I go debug inside the CRT, the
> owning threadid is set to -1, so I'm not sure.  Maybe something's been
> uninitialized by this point.  I thought of using ManagedStatic<> to better
> control the uninitialization of the mutex, but I don't think that really
> solves the problem.  The issue is that we're even relying on a mutex at all
> during CRT shutdown.
>
>
>
> On Thu, May 29, 2014 at 2:44 PM, Aaron Ballman <aaron at aaronballman.com>
> wrote:
>
>> On Thu, May 29, 2014 at 5:41 PM, Zachary Turner <zturner at google.com>
>> wrote:
>> > What command are you using to run the tests?  I'm still a new
>> contributor,
>> > and am not familiar with how to do everything, but I run ninja
>> check-all and
>> > while it doesn't seem to be finishing, I am not getting any output.
>>  How can
>> > I get a command line of a single test that I can easily run
>> independently on
>> > the command line to reproduce a deadlock so I can look into this
>> further?
>>
>> I was running my tests from within MSVC by building the check-clang
>> project; output pipes automatically into the output window as the
>> tests run. You can use python and llvm-lit to run specific tests from
>> the command line. Eg) python.exe ./bin/llvm-lit.py -v
>> ../tools/clang/test/Sema/warn-thread-safety-analysis.c
>>
>> HTH!
>>
>> ~Aaron
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140529/dfed5e46/attachment.html>