Bug #18444
openTrapped TSTP causes a locking deadlock in 3.0.3 onward
Description
A curious case:
ruby -e 'Signal.trap("TSTP") { puts "Received a terminal stop signal, but i will sleep instead."; sleep 10 }; loop {puts 1}'
this fails with deadlock; recursive locking (ThreadError)
when I send the SIGTSTP via my terminal. This is on Mac OS Monterey (M1). It only happens in 3.0.3 and onward (I tried 3.1.0-preview1 as well, fails there too), when I try 3.0.2, the signal is handled properly.
Updated by jeremyevans0 (Jeremy Evans) almost 3 years ago
I couldn't replicate this behavior in OpenBSD/amd64. On OpenBSD/amd64, sending TSTP prints the Received... string twice, 10 seconds part, followed by the loop printing 1. Windows doesn't support TSTP, so no reason to test there. Can anyone replicate this outside of M1 MacOS?
Updated by xtkoba (Tee KOBAYASHI) over 2 years ago
I tested this on several Linux (GNU/Linux and Android) environments. Sending Ctrl-Z
from terminal sometimes results in "Received ..." and sometimes "deadlock" but not sticking to one result for each environment. I used the newest released versions of Ruby (2.7.6, 3.0.4, 3.1.2) but not sure what happens for older versions.
Tested environments:
$ ruby27 -v
ruby 2.7.6p219 (2022-04-12 revision c9c2245c0a) [x86_64-linux]
$ ruby30 -v
ruby 3.0.4p208 (2022-04-12 revision 3fa771dded) [x86_64-linux]
$ ruby31 -v
ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) [x86_64-linux]
$ uname -a
Linux localhost 5.4.188-gentoo #1 SMP Wed Mar 30 09:04:25 JST 2022 x86_64 Intel(R) Core(TM)2 CPU U7500 @ 1.06GHz GenuineIntel GNU/Linux
$ ruby -v
ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) [arm-linux-android]
$ uname -a
Linux localhost 3.10.49-g12ec2e6-00359-g4edd381 #1 SMP PREEMPT Tue Sep 26 20:27:28 CST 2017 armv7l
$ ruby -v
ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) [aarch64-linux-android]
$ uname -a
Linux localhost 4.9.82-perf+ #1 SMP PREEMPT Wed Feb 27 13:05:28 CST 2019 aarch64