Re: Async cacellation and pthread_cleanup_push

[Florian Weimer via Libc-alpha <libc-alpha@sourceware.org>]

* Andreas Schwab:

> On Aug 23 2021, Florian Weimer wrote:
>
>> * Andreas Schwab:
>>
>>> On Aug 04 2021, Florian Weimer wrote:
>>>
>>>> * Andreas Schwab:
>>>>
>>>>> On Aug 04 2021, Florian Weimer wrote:
>>>>>
>>>>>> * Andreas Schwab:
>>>>>>
>>>>>>> Is pthread_cleanup_push supposed to work together with async
>>>>>>> cancellation?
>>>>>>
>>>>>> In our implementation?  I think so.
>>>>>
>>>>> I don't see how that can work with -fexceptions or in C++, though.  Is
>>>>> that supported?
>>>>
>>>> I think it is supposed to work, but it probably is unreliable.
>>>
>>> Since the compiler puts the exception regions only over function calls
>>> (and -fnon-call-exceptions only covers potentially trapping insns in
>>> addition) the cleanup region will not be fully covered.
>>
>> I can see how this can happen in theory …
>
> This is not theory, it happens exactly here.
>
>>> testcases/open_posix_testsuite/conformance/interfaces/pthread_cancel/3-1.c
>>
>> … but I don't see how this applies to this particular test.
>
> There is a non-zero probability that the cancel signal arrives in
> thread_func and sleep_loop while it is executing the unprotected
> instructions outside of the .LEHB1 to .LEHE1 region:
>
>         movl    $sem, %edi
>         call    sem_post
>         movq    $0, (%rsp)
>         movq    $1000000, 8(%rsp)
>         .p2align 4,,10
>         .p2align 3
> .L2:
>         xorl    %esi, %esi
>         movq    %rsp, %rdi
> .LEHB1:
>         call    nanosleep
>         subl    $1, %ebx
>         jne     .L2
>         movl    $.LC0, %edi
>         call    puts
> .LEHE1:

Odd.

Does this happen because sem_post is annotated with __THROWNL?

GCC should ignore __attribute__ ((nothrow)) with -fnon-call-exceptions.

Thanks,
Florian