Re[2]: wait skips signals but first one

[Mykyta Dorokhin]

Hello again,

configure log says:

checking if getcwd() will dynamically allocate memory with 0 size... (cached) 
yes
checking for presence of POSIX-style sigsetjmp/siglongjmp... (cached) missing
checking whether or not strcoll and strcmp differ... (cached) no

This is most likelly the problem.

Note 1: forgot to mention that I'm cross-compiling. 
Note 2: it probably makes sense to add a warning or something that states that 
HAVE_POSIX_SIGSETJMP disabled due to cross-compiling.

Will try to find a way to fix this.

Thank you  for your time! You are doing a great job!


M




5 февраля 2024, 16:28:36, от "Chet Ramey" <chet.ramey@case.edu>:

On 2/3/24 7:01 PM, Mykyta Dorokhin wrote:

> There is a line in trap.c with your change. If I revert it then everything 
> works again:
> 
> - if (interrupt_immediately && wait_intr_flag)
> + if (/* interrupt_immediately && */wait_intr_flag)
> 
> So if I put interrupt_immediately back and rebuild the code with thes only 
> fix then it starts working properly, signals are getting received as expected.

OK. Let's look at that. By this time, interrupt_immediately was no longer
set anywhere, so the code before this change did nothing but inhibit the
siglongjmp/longjmp call from trap_handler, which means the sighandler
returned and (possibly) did not interrupt the wait builtin.

That is what this means (replace SIGINT with SIGUSR1 here):

>     The one change that might make a difference is a bug fix: if the wait
>     builtin is waiting for a process and receives a trapped signal, it's
>     supposed to cause wait to return immediately and then run the trap. Bash
>     didn't do that consistently for SIGINT, and would run the trap when it
>     shouldn't, or before it should, and sometimes not return from the wait
>     at all. So maybe the longjmp back to the wait builtin is what changed
>     things, even though longjmp is one of the functions that POSIX says is
>     safe to call from a signal handler context, and it restores the signal
>     mask if you're running on a system that has sigsetjmp/siglongjmp.

So the effect of this change is to longjmp/siglongjmp back to the wait
builtin, so it can return from there before running the trap. If you use
siglongjmp, it restores the original signal mask (look at the wait
builtin's call to setjmp_sigs, a macro that calls sigsetjmp with 1 as the
second argument), which means the trapped signal is no longer blocked.

Since this works as intended on all other systems, I would check to see
if your system has sigsetjmp/siglongjmp and whether or not they are
behaving correctly.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/