On Mon, Aug 4, 2014 at 7:29 PM, Jonathan Wakely <jwakely....@gmail.com> wrote:
>>>>>> These two tests timeout on alpha-linux-gnu:
>>>>>>
>>>>>> FAIL: 30_threads/async/forced_unwind.cc execution test
>>>>>> WARNING: program timed out.
>>>>>> FAIL: 30_threads/packaged_task/forced_unwind.cc execution test
>>>>>> WARNING: program timed out.
>>>>>
>>>>>
>>>>>
>>>>> Sorry about that, I don't know why.
>>>>>
>>>>> Does pthread_exit(0) use a __forced_unwind exception on
>>>>> alpha-linux-gnu? This should tell you ...
>>>>>
>>>>>
>>>>> #include <bits/cxxabi_forced.h>
>>>>> #include <pthread.h>
>>>>>
>>>>> void* f(void*) {
>>>>> try
>>>>> {
>>>>> pthread_exit(0);
>>>>> }
>>>>> catch (__cxxabiv1::__forced_unwind const&)
>>>>> {
>>>>> __builtin_puts("unwind");
>>>>> throw;
>>>>> }
>>>>> catch (...)
>>>>> {
>>>>> __builtin_puts("something else");
>>>>> throw;
>>>>> }
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>> pthread_t t;
>>>>> pthread_create(&t, 0, f, 0);
>>>>> pthread_join(t, 0);
>>>>>
>>>>> }
>>>>
>>>>
>>>> Strange, I don't get anything ...
>>>>
>>>> $ g++ -lpthread pt.C
>>>> $ ./a.out
>>>
>>>
>>> That explains it then: the thread just goes away, and the waiting
>>> function hangs forever expecting the future to be made ready.
>>>
>>> The test assumes pthread_exit is implemented by throwing
>>> __forced_unwind, which apparently isn't true for all glibc targets.
>>>
>>> If the thread just goes away there's no way to make the future ready.
>>> I guess we should just XFAIL it for alpha, and maybe other targets.
>>
>> Actually, the testcase uncovered a target bug in glibc NPTL, where
>> saved stack pointer value in jmp_buf is not mangled as expected by
>> unwind_stop function. The detailed analysis is available at [1].
>>
>> [1] https://sourceware.org/bugzilla/show_bug.cgi?id=17165
>>
>> Uros.
>
> Uros, would backporting this to the 4.9 branch cause problems for alpha?
No, I don't think so. The problem was identified as glibc bug that was
fixed almost a year ago for 2.18.
> I assume since the change is already on trunk and the glibc bug is
> already fixed that putting it on the 4.9 branch wouldn't make things
> any worse than they are now?
No. As said before, it is not gcc's fault.
Uros.
