On 4/22/26 5:30 AM, František Šumšal wrote:

Bash Version: 5.3
Patch Level: 0
Release Status: release

Description:
Hello! Recently I was debugging a very strange fail in our systemd test suite, 
and after some digging I noticed it was
caused by a bash script that was being used as a stub init for a test 
container. To test if the signal delivery to the
container's init works properly, the stub init has several traps defined for 
various signals, which are then probed and
checked. However, in a couple of cases the stub init entered a busy loop and 
trashed the machine. A minimized version
of the stub init can be found in the Repeat-by section below.

Thanks for the detailed analysis and fix. Your fix is the simplest way to
solve this problem.

    - (!!) run_interrup_trap() unconditionally resets catch_flag to 0 even 
though we still have a pending signal (SIGNAL2)

This is the issue. catch_flag is a semaphore indicating we have a pending
trap to execute. run_interrupt_trap() shouldn't reset it to 0 because we
don't go through all the signals.

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

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature

Reply via email to