This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] Update catch(...) handlers to deal with __forced_unwind


On Mon, Aug 4, 2014 at 7:29 PM, Jonathan Wakely <jwakely.gcc@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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]