[cfe-dev] libc++ mutex destructor assertion

David Majnemer david.majnemer at gmail.com
Fri Jun 13 10:32:49 PDT 2014


On Fri, Jun 13, 2014 at 12:42 PM, Chandler Carruth <chandlerc at google.com>
wrote:

>
> On Fri, Jun 13, 2014 at 5:29 PM, Zachary Turner <zturner at google.com>
> wrote:
>
>> Currently recursive_mutex::~recursive_mutex() asserts if
>> pthread_mutex_destroy fails, and one of the reasons this can fail is if the
>> mutex is locked by another thread.  This leads to the assert being
>> triggered in the following sample program:
>>
>> #include <mutex>
>> #include <stdlib.h>
>> #include <stdio.h>
>>
>> std::recursive_mutex& getMutex() {
>>   static std::recursive_mutex mutex;
>>   return mutex;
>> }
>>
>> void* ThreadFunc(void* arg) {
>>   std::lock_guard<std::recursive_mutex> Lock(getMutex());
>>   exit(1);
>>   return nullptr;
>> }
>>
>>
>> int main(int argc, char** argv) {
>>   pthread_t thread;
>>   pthread_attr_t attr;
>>
>>   pthread_attr_init(&attr);
>>   pthread_create(&thread, &attr, ThreadFunc, nullptr);
>>   pthread_join(thread, nullptr);
>>
>>   return 0;
>> }
>>
>>
>> Is this assertion bogus?  I'm trying to replace a mutex in LLVM with
>> recursive_mutex but am blocked by this because the builder on FreeBSD
>> actually aborts here due to the assertion.
>>
>> What's the best way to go about resolving this?  Even if we decide that
>> the assertion should be removed, it's not going to stop the builders from
>> failing every time until they get a new build of libc++, and I don't think
>> (but maybe I'm wrong?) the builders build libc++, but rather just use the
>> one that's already installed.
>>
>
> The C++ spec says that it is UB to destroy a mutex which is locked. I find
> this completely ridiculous bordering on insanity, but there it is. libc++
> is correct here (unless I can get this restriction removed).
>

It is very reasonable for this to be UB.  Imagine a mutex where memory is
allocated in pthread_mutex_init and free'd in pthread_mutex_destroy.
 Unlocks which race with the destruction may end up partying on free'd
memory.


>
> It's very easy to support this -- just don't call pthread_mutex_destroy(),
> the function has no purpose really.
>

This is not true. Some implementations, like FreeBSD's libthr, free memory
in their pthread_mutex_destroy.  Not calling pthread_mutex_destroy will
lead to leaks.



>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140613/10971706/attachment.html>


More information about the cfe-dev mailing list