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

[Andrew Ng via llvm-commits]

I'm not sure if this is related, but I've been investigating exit crashes
on Windows with respect to the std::thread based implementation of the
thread pool. One of the issues I encountered was a race condition between
the main thread calling exit() and the first thread of the thread pool
still creating worker threads. Could this be a possible issue in this case
too? The more cores you have, the longer the thread pool "spin up" can
take, expanding the window for such a race to occur.

Cheers,
Andrew

On 28 October 2017 at 12:02, NAKAMURA Takumi via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> On Sat, Oct 28, 2017 at 3:32 AM Rui Ueyama <ruiu at google.com> wrote:
>
>> 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?
>>
>
> No. std::thread is not culprit (but it doesn't have
> PTHREAD_CREATE_DETACHED)
> I can reproduce the crash without std::thread, but with naked pthreads.
> Without "for (...) *p;", pthread_detach() crashes rarely.
> With *p, *p raises segv in the loop (not in the 1st iteration).
>
>
>> If so, does calling a pthread function (e.g. pthread_cond_timedwait with
>> timeout value of 1) make it wait until it's ready?
>>
>
> I think it doesn't make sense. Rather than waiting for particular
> condition, I suggest to make the thread detached not in caller context.
>
> FYI, usleep(1000);pthread_detach() can hide the issue.
>
> 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
>>>
>>>
>>
> _______________________________________________
> 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/20171030/a7dab505/attachment.html>