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

[Rafael Avila de Espindola via llvm-commits]

If the issue is some race between creation and detach, maybe we could do
something like

      for (size_t i = 1; i < ThreadCount; ++i) {
        std::thread T([=] { <set cond variable> work(); });
        <wait for cond variable>
        T.detach();
      }

Cheers,
Rafael

Andrew Ng via llvm-commits <llvm-commits at lists.llvm.org> writes:

> 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
>>
>>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits