This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Race condition in multiprocessing/connection.py: broken handle
Type: behavior Stage: patch review
Components: Library (Lib) Versions: Python 3.9, Python 3.8, Python 3.7
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: maxicooper, pitrou, remi.lapeyre, vstinner
Priority: normal Keywords: patch

Created on 2020-04-27 02:31 by maxicooper, last changed 2022-04-11 14:59 by admin.

Pull Requests
URL Status Linked Edit
PR 19790 open remi.lapeyre, 2020-04-29 10:27
Messages (6)
msg367355 - (view) Author: Maxi (maxicooper) Date: 2020-04-27 02:31
## Sorry if this is not properly created, my first time here ##

I'm experiencing random Exceptions originating in multiprocessing/connection.py:368 where the handle seems to be broken:

Apr 25 19:39:44 app python[26282]:   File "/usr/lib/python3.5/multiprocessing/managers.py", line 716, in _callmethod
Apr 25 19:39:44 app python[26282]:     conn.send((self._id, methodname, args, kwds))
Apr 25 19:39:44 app python[26282]:   File "/usr/lib/python3.5/multiprocessing/connection.py", line 206, in send
Apr 25 19:39:44 app python[26282]:     self._send_bytes(ForkingPickler.dumps(obj))
Apr 25 19:39:44 app python[26282]:   File "/usr/lib/python3.5/multiprocessing/connection.py", line 404, in _send_bytes
Apr 25 19:39:44 app python[26282]:     self._send(header + buf)
Apr 25 19:39:44 app python[26282]:   File "/usr/lib/python3.5/multiprocessing/connection.py", line 368, in _send
Apr 25 19:39:44 app python[26282]:     n = write(self._handle, buf)
Apr 25 19:39:44 app python[26282]: TypeError: an integer is required (got type NoneType)

Not sure if there is something wrong at OS level, but I think a self._check_closed() before that line would help.
msg367408 - (view) Author: Rémi Lapeyre (remi.lapeyre) * Date: 2020-04-27 09:01
Hi Maxi, Python 3.5 now only accept security fixes. Can you reproduce this issue with recent releases and post an example here?
msg367418 - (view) Author: Maxi (maxicooper) Date: 2020-04-27 13:23
Hi Rémi. This is a production environment and can't reproduce it in the dev server (probably because of the lack of volume).

I did checked that the code is the same up to Python 3.8, but can't confirm an actual case until we upgrade in prod.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, 27 de April de 2020 6:01, Rémi Lapeyre <report@bugs.python.org> wrote:

> Rémi Lapeyre remi.lapeyre@henki.fr added the comment:
>
> Hi Maxi, Python 3.5 now only accept security fixes. Can you reproduce this issue with recent releases and post an example here?
>
> ----------------------------------------------------------------------------------------------------------------------------------
>
> nosy: +remi.lapeyre
> type: crash -> behavior
>
> Python tracker report@bugs.python.org
> https://bugs.python.org/issue40402
msg367441 - (view) Author: Rémi Lapeyre (remi.lapeyre) * Date: 2020-04-27 17:37
A call to self._check_closed() is already present in Python 3.5 https://github.com/python/cpython/blob/3.5/Lib/multiprocessing/connection.py#L202-L206

It is possible for some issues to appear when mixing multiprocessing and multithreading thought:

In [17]: from time import sleep 
    ...: import multiprocessing, threading 
    ...:  
    ...: class Test: 
    ...:     def __reduce__(self): 
    ...:         sleep(1) 
    ...:         return (Test, ()) 
    ...:  
    ...: parent, child = multiprocessing.Pipe() 
    ...: threading.Thread(target=lambda: parent.send(Test())).start() 
    ...: parent.close()                                                                         

Exception in thread Thread-7:
Traceback (most recent call last):
  File "/Users/remi/src/cpython/Lib/threading.py", line 950, in _bootstrap_inner
    self.run()
  File "/Users/remi/src/cpython/Lib/threading.py", line 888, in run
    self._target(*self._args, **self._kwargs)
  File "<ipython-input-17-43406d743010>", line 10, in <lambda>
/Users/remi/src/cpython/venv/lib/python3.9/site-packages/prompt_toolkit/renderer.py:514: DeprecationWarning: The explicit passing of coroutine objects to asyncio.wait() is deprecated since Python 3.8, and scheduled for removal in Python 3.11.
  await wait(coroutines, return_when=FIRST_COMPLETED)
  File "/Users/remi/src/cpython/Lib/multiprocessing/connection.py", line 211, in send
    self._send_bytes(_ForkingPickler.dumps(obj))
  File "/Users/remi/src/cpython/Lib/multiprocessing/connection.py", line 416, in _send_bytes
    self._send(header + buf)
  File "/Users/remi/src/cpython/Lib/multiprocessing/connection.py", line 373, in _send
    n = write(self._handle, buf)
TypeError: an integer is required (got type NoneType)



Maybe using a try-catch block could be more appropriate than the current check.

CC-ing Antoine Pitrou as he is the original author of this part in 87cf220972c9cb400ddcd577962883dcc5dca51a. If you are OK with replacing calls to self._check_closed() by an exception block I would be happy to open a PR for this.
msg367442 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2020-04-27 18:11
I don't know if a try..except block is the best solution, but feel free to submit a PR and we can iterate on that :-)
msg367706 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2020-04-29 21:57
See also bpo-39995: race condition in concurrent.futures. More specific to _ThreadWakeup class, but with similar symptoms.
History
Date User Action Args
2022-04-11 14:59:29adminsetgithub: 84582
2020-04-29 21:57:47vstinnersetnosy: + vstinner
messages: + msg367706
2020-04-29 10:27:09remi.lapeyresetkeywords: + patch
stage: needs patch -> patch review
pull_requests: + pull_request19113
2020-04-27 18:11:46pitrousetmessages: + msg367442
stage: needs patch
2020-04-27 17:37:48remi.lapeyresetnosy: + pitrou
versions: + Python 3.7, Python 3.8, Python 3.9, - Python 3.5
messages: + msg367441

components: + Library (Lib)
title: multiprocessing/connection.py broken handle -> Race condition in multiprocessing/connection.py: broken handle
2020-04-27 13:23:42maxicoopersetmessages: + msg367418
2020-04-27 09:01:53remi.lapeyresetnosy: + remi.lapeyre
type: crash -> behavior
messages: + msg367408
2020-04-27 02:31:49maxicoopercreate