17

Occurs at least on GNU bash version 4.3.42 x86_64 && GNU bash version 4.3.11 x86_64

I use sleep & wait $! instead of a simple sleep for getting an interruptible sleep by a signal (as SIGUSR1). But it seems that the wait bash-builtin behaves in a strange way when you run the following.

Terminal 1:

cat <(
   trap 'echo SIGUSR1' SIGUSR1;
   echo $BASHPID;
   while :;do
       sleep 1 &
       wait $!;
       echo test;
   done
   )&

Terminal 2:

kill -10 /the pid of the subshell, printed by the previous command/

Terminal 1:

^C (ctrl + C)

Then, I get the subshell that burns a CPU at 100 percent.

Terminal 1:

pkill -P $(pgrep -P $$)

Do you have any idea about why this behavior occurs?

NB: no problem occurs when the cat <(/subshell/) isn't in the background.

Another way to experience this behavior

Terminal 1:

(
   trap 'echo SIGUSR1' SIGUSR1;
   echo $BASHPID;
   while :;do
       sleep 1 &
       wait $!;
       echo test;
   done
)&

Terminal 2:

kill -10 /the pid of the subshell, printed by the previous command/

Terminal 1:

fg
^C (ctrl + C)

Then, get a frozen shell.

A third way to experience this behavior

Terminal 1:

(
   trap 'echo SIGUSR1' SIGUSR1;
   echo $BASHPID;
   while :;do
       sleep 1 &
       wait $!;
       echo test;
   done
)

Terminal 2:

kill -10 /the pid of the subshell, printed by the previous command/

Terminal 1:

^C (ctrl + C)

Then, get a frozen shell.

Community
  • 1
M89
  • 758
  • 1
  • 5
  • 10
  • To debug this, you probably have to build Bash from sources and find out where it is looping (break it with a debugger or add print statements) and why it is looping. – Kaz Sep 05 '16 at 16:37
  • 1
    Strange? I cant reproduce this here, i am using bash 4.3.42(1)-release (x86_64-pc-linux-gnu). Debian 8. Kernel 4.6.1-1. I do all the tests that you say but the CPU still running normally... I am doing exactly like you say including the fg, and then CTRL+C. – Luciano Andress Martini Sep 16 '16 at 18:48
  • I remember reading that some things related to built-ins and signals changed in `bash` 4.4, maybe this here could be affected. – phk Dec 17 '16 at 23:34
  • [Bash 4.4.20](https://ftp.gnu.org/gnu/bash/bash-4.4-patches/bash44-020) fixes a spinloop issue on `wait` that looks very similar to this. I was hit by that in a loop that spawned sub-processes forever. However, I tested your scenario on 4.4.20 and it was still a problem. Interestingly, when I attached a debugger on a version I built, I could see it was looping around, but it *also* had the effect of breaking out of it, and the loop would start outputting 'test' again. In other words: attaching the debugger made it stop spinlooping. – Halfgaar Apr 02 '19 at 13:38

1 Answers1

1

Observations

  • ctrl+c sends SIGINT to the fg-process in Terminal 1
  • hence, executing kill -2 <PID> in Terminal 2 is the same as hitting ctrl+c in Terminal 1
  • doing one of the two above points before executing kill -10 <PID> in Terminal 2 handles SIGINT correctly
  • doing it after executing kill -10 <PID> in Terminal 2 (sending signal SIGUSR1) doesn't handle SIGINT correctly and leads to the problematic behaviour
  • Replacing kill -2 <PID> in Terminal 2 (SIGINT) with kill -15 <PID> (SIGTERM) or kill -9 <PID> (SIGKILL) leads always to correct signal handling.
  • executing kill -10 <PID> in Terminal 2 interrupts the wait builtin but doesn't leave the loop since test is immediately printet after the signal SIGUSR1 is trapped and the loop continues.
  • Sending SIGINT breaks out of the executing loop and freezes the shell or it never interrupts wait and stays waiting/frozen.

Conclusion

SIGINT is not cought and handled correctly or it is ignored after manually trapping SIGUSR1 or maybe any other user defined trapping. That means that the process still exists and that's why it eats/heats up the CPU or freezes the shell. Executing kill -15 <PID> or kill -9 <PID> from Terminal 2 terminates/kills the process and gives you back the control over Terminal 1 and relaxes your CPU.

Why this problem occurs, still remains a mystery, but I hope somebody can explain exactly what is really happenening behind the curtains.

Neni
  • 125
  • 6