Signal handler sometimes not called
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 77.2k
- Forks
- 36k
- PR merge metrics
- PR metrics pending
Description
Bug report
Below is a program repoducing the issue. Two Python processes P (as Parent) and CH (as child) are exchanging SIGUSR1 signals. One process waits for a signal, the other one sends it. Then they switch the roles and the signal si sent the other way. This is repeated in a loop. After few seconds the loop halts, usually before reaching 1000 iterations (on my computer). I believe that a signal was delivered to the process, but the corresponding handler was not called.
import fcntl, os, subprocess, signal, sys, time
label: str # either P (parent) or CH (child)
def selfpipe(signo: int) -> int:
rfd, wfd = os.pipe()
wflags = fcntl.fcntl(wfd, fcntl.F_GETFL)
fcntl.fcntl(wfd, fcntl.F_SETFL, wflags | os.O_NONBLOCK)
msg = f"{label} handler\n".encode('ascii')
def signal_handler(*_):
# write() is "async-signal-safe"
os.write(1, msg)
os.write(wfd, b"\x00")
signal.signal(signo, signal_handler)
return rfd
def main():
global label
is_child = sys.argv[1:2] == ["CH"]
label = "CH:" if is_child else "P:"
rfd = selfpipe(signal.SIGUSR1)
if is_child:
other = os.getppid()
else:
child = subprocess.Popen(["python3", sys.argv[0], "CH"])
other = child.pid
if is_child:
# parent starts with wait, child starts with signal
os.kill(other, signal.SIGUSR1)
i = 0
while True:
print(f"{label} wait")
os.read(rfd, 1)
print(f"{label} signal {i}")
os.kill(other, signal.SIGUSR1)
time.sleep(0.02) # reduce CPU load
i += 1
if __name__ == "__main__":
main()
Your environment
Linux x86 PC, tested on Python 3.7.14, 3.8.14 and 3.10.7
Notes
-
I made a C program exchanging signals the same way and it does not halt
-
It is known that if a signal is pending (delivered, but not processed yet), sending another signal of the same type has no effect. That explains "lost" signals in some situations. Tthis cannot be such case, because the next signal comes only after the current signal has been acted upon.
-
Despite both processes executing the same loop, the test always hangs with the last signal sent from P to CH, not in the other direction.
CH: handler
CH: wait
CH: signal 521
P: handler
P: wait
P: signal 522 <-- always P (never CH) in my tests
CH: wait
P: wait <-- last line before halt
- When terminating the test with ctrl-C, the signal handler gets called! That proves the signal was delivered.
^CCH: handler <--- note the message from the signal handler
Traceback (most recent call last):
File "/tmp/pp/sigdemo.py", line 44, in <module>
Traceback (most recent call last):
File "/tmp/pp/sigdemo.py", line 44, in <module>
main()
File "/tmp/pp/sigdemo.py", line 37, in main
main()
File "/tmp/pp/sigdemo.py", line 37, in main
os.read(rfd, 1)
KeyboardInterrupt
os.read(rfd, 1)
KeyboardInterrupt
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Run the supplied reproducer through its selfpipe() and main() entry points on the Python versions and Linux environment described, then compare it with the C program mentioned in the notes. Trace the SIGUSR1 handling around os.read(), os.kill(), and the signal handler; done means the parent and child continue exchanging signals instead of halting.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- operating-systems
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 42/100