std::thread::detach() rarely crashes in Parallel.cpp

Rui Ueyama via llvm-commits llvm-commits at lists.llvm.org
Fri Oct 27 11:31:51 PDT 2017


Does that mean that std::thread touches a thread object in an unexpected
way before it's ready, and all pthread_* functions would work because they
are well-behaved?

If so, does calling a pthread function (e.g. pthread_cond_timedwait with
timeout value of 1) make it wait until it's ready?

On Fri, Oct 27, 2017 at 5:56 AM, NAKAMURA Takumi via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> It was discussed in https://reviews.llvm.org/D39038
>
> I suffered when check-lld behaves flaky. For example; http://lab.llvm.org:
> 8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/19673
>
> I have been investigating and I guess it triggered bug or something in
> libpthread or Linux kernel.
> pthread_detach() in std::thread::detach() is crashing with segv.
> Seems pthread (internal struct in Linux nptl) is inaccessible.
> The crash is reproducible w/o std::thread, but with libpthread.
> In my environment, crash can be seen several times per million attempt.
>
> This is my testcase. (in Parallel.cpp)
>
>         pthread_t th;
>         auto r = pthread_create(&th, nullptr, worker_stub, (void*)this);
>         (void)r;
>         assert(r == 0);
>         auto p = reinterpret_cast<volatile int*>(th);
>         for (int j = 0; j < 1000 * 1000; ++j)
>           *p;
>         pthread_detach(th);
>
> Accessing *p sometimes raises segv.
>
> Ideally, Linux (or distro) should be fixed, but I suppose the distro,
> Ubuntu 14.04 is widely used.
> I would like to propose we could avoid std::thread().detach()
>
> As far as I tried, this successfully runs to me with million of iterations.
> - Use naked pthread_create()
>   a) Create the thread with PTHREAD_CREATE_DETACHED
>   b) Do pthread_detach(pthread_self()) in the worker thread.
>
> Note, (b) doesn't work with std::thread.
>
> Takumi
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20171027/779cc2d4/attachment.html>


More information about the llvm-commits mailing list