Re: Possible busy-loop in signal handling with a trap calling an external command

On Wed, Apr 22, 2026 at 9:01 AM František Šumšal <[email protected]> wrote:
>
> Fix:
> A naive solution would be to reset the catch_flag in run_interrupt_trap() only if there's no pending signal, i.e.:
>
> diff --git a/trap.c b/trap.c
> index 5cf8a1bd..dc806822 100644
> --- a/trap.c
> +++ b/trap.c
> @@ -1351,7 +1351,8 @@ run_interrupt_trap (int will_throw)
>     if (will_throw && running_trap > 0)
>       run_trap_cleanup (running_trap - 1);
>     pending_traps[SIGINT] = 0;   /* run_pending_traps does this */
> -  catch_flag = 0;
> +  if (first_pending_trap () == -1)
> +    catch_flag = 0;
>     _run_trap_internal (SIGINT, "interrupt trap");
>   }
>
> Which does seem to help in this case, but I'm not sure about any potential side effects this change could have.

Alternatively, catch_flag could be replaced by a variable that counts
how many pending signals there are.