[PATCH v2 1/2] setjmp: Use BSD sematic as default for setjmp

Florian Weimer fweimer@redhat.com
Mon Aug 7 12:54:08 GMT 2023


* Adhemerval Zanella Netto:

> On 04/08/23 05:43, Florian Weimer wrote:
>> * Adhemerval Zanella:
>> 
>>> POSIX relaxed the relation of setjmp/longjmp and the signal mask
>>> save/restore, meaning that setjmp does not require to be routed to
>>> _setjmp to be standard compliant.
>>>
>>> This is done to avoid breakage of SIGABRT handlers, since to fully
>>> make abort AS-safe, it is required to remove the recurisve lock
>>> used to unblock SIGABRT prior raised the signal.
>>>
>>> Also, it allows caller to actually use setjmp, since from
>>> 7011c2622fe3e10a29dbe74f06aaebd07710127d the symbol is unconditionally
>>> routed to _setjmp.
>> 
>> I still think we shouldn't do this due to the performance implications.
>
> By not changing it and with the abort AS-safe fix, the following code
> will always abort the program:
>
> --
>  static jmp_buf jb;
>
>  static void
>  sigabrt_handler (int sig)
>  {
>    longjmp (jb, 1);
>  }
>
>  struct sigaction sa = { .sa_handler = sigabrt_handler, .sa_flags = 0 };
>  sigemptyset (&sa.sa_mask);
>  assert (sigaction (SIGABRT, &sa, 0) == 0);
>
>  if (setjmp (jb) == 0)
>    abort ();
>
>  if (setjmp (jb) == 0)
>    abort ();
>
>  // No reached.
> --
>
> Callers will need to change to sigsetjmp (..., 1) to have the same semantic.
> That's the main reason I am suggesting this patch.

Could we just unconditionally unblock SIGABRT at the start of abort,
before the raise (SIGABRT) call?  Other signal handlers could still
observe this, but I think this change isn't really part of the core
async signal safety fix.

Thanks,
Florian



More information about the Libc-alpha mailing list