[cfe-dev] libc++ mutex destructor assertion

[Chandler Carruth]

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's very easy to support this -- just don't call pthread_mutex_destroy(),
the function has no purpose really.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140613/f0c209ea/attachment.html>