[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