This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC 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 16 July 2014 17:22, Uros Bizjak <ubizjak@gmail.com> wrote:
> On Fri, Jun 6, 2014 at 4:31 PM, Jonathan Wakely <jwakely@redhat.com> wrote:
>> On 06/06/14 12:40 +0200, Uros Bizjak wrote:
>>>
>>> On Fri, Jun 6, 2014 at 11:19 AM, Jonathan Wakely <jwakely@redhat.com>
>>> wrote:
>>>>
>>>> On 06/06/14 10:27 +0200, Uros Bizjak 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?

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?

The change is needed to make the code correct in the face of pthread
cancellations.


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