classification
Title: With forkserver, Process.exitcode does not get signal number
Type: behavior Stage: resolved
Components: Library (Lib) Versions: Python 3.7
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: davin, pitrou, sbt
Priority: normal Keywords:

Created on 2017-06-07 15:21 by pitrou, last changed 2017-06-30 08:37 by pitrou. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 1989 merged pitrou, 2017-06-08 00:38
Messages (4)
msg295343 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2017-06-07 15:21
The documentation for multiprocessing.exitcode says:
"""
    The child’s exit code. This will be None if the process has not yet terminated. A negative value -N indicates that the child was terminated by signal N.
"""

This is true for the "fork" method, but not "forkserver" where a child terminated by a signal will get an exitcode of 255.  This is because forkserver relies on the child writing its own exit code in a pipe, which obviously doesn't work if it was killed (255 is simply a fallback value).

See forkserver's Popen.poll():

    def poll(self, flag=os.WNOHANG):
        if self.returncode is None:
            from multiprocessing.connection import wait
            timeout = 0 if flag == os.WNOHANG else None
            if not wait([self.sentinel], timeout):
                return None
            try:
                self.returncode = forkserver.read_unsigned(self.sentinel)
            except (OSError, EOFError):
                # The process ended abnormally perhaps because of a signal
                self.returncode = 255
        return self.returncode
msg295778 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2017-06-12 13:28
New changeset dfd5f34634f9c505945e9348b4b799544680a7cf by Antoine Pitrou in branch 'master':
Fix bpo-30589: improve Process.exitcode with forkserver (#1989)
https://github.com/python/cpython/commit/dfd5f34634f9c505945e9348b4b799544680a7cf
msg295779 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2017-06-12 13:29
I've merged a fix for Python 3.7.  Since the fix is a bit delicate, I don't want to risk regression by merging it into 3.6 and 3.5. Closing now.
msg297360 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2017-06-30 08:37
In the end, I'm glad I added a stress test (test_many_processes) as part of this issue.

It helper uncover a serious reliability issues in CPython's delivery of signals (https://bugs.python.org/issue30703) and then triggered the discovery of a more minor bug in our setitimer() wrapper (https://bugs.python.org/issue30807).

Hopefully signal processing is more reliable in Python now!
History
Date User Action Args
2017-06-30 08:37:05pitrousetmessages: + msg297360
2017-06-12 13:29:17pitrousetstatus: open -> closed
versions: - Python 3.5, Python 3.6
messages: + msg295779

resolution: fixed
stage: patch review -> resolved
2017-06-12 13:28:21pitrousetmessages: + msg295778
2017-06-08 00:38:34pitrousetstage: patch review
2017-06-08 00:38:17pitrousetpull_requests: + pull_request2055
2017-06-07 15:21:05pitroucreate