You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
assignee=Noneclosed_at=<Date2018-09-07.12:23:22.942>created_at=<Date2018-09-01.16:52:43.549>labels= ['3.8', '3.7', 'library', 'type-crash']
title='invalid assert on big output of multiprocessing.Process'updated_at=<Date2018-09-07.15:37:51.831>user='https://github.com/ahcub'
the bug is reproduced on big multiprocessing.Process output
when the size of the output gets bigger than signed int the value becomes negative, thus
assert left > 0
in multiprocessing/connection.py:337 raises an exception like the following
Traceback (most recent call last):
File "D:\GitHub\cpython\lib\threading.py", line 917, in _bootstrap_inner
File "D:\GitHub\cpython\lib\threading.py", line 865, in run
File "D:\GitHub\cpython\lib\multiprocessing\pool.py", line 470, in _handle_results
task = get()
File "D:\GitHub\cpython\lib\multiprocessing\connection.py", line 250, in recv
buf = self._recv_bytes()
File "D:\GitHub\cpython\lib\multiprocessing\connection.py", line 318, in _recv_bytes
return self._get_more_data(ov, maxsize)
File "D:\GitHub\cpython\lib\multiprocessing\connection.py", line 337, in _get_more_data
assert left > 0
this assert looks invalid in this case because in C code the left value is DWORD (unsigned long), which cannot be negative by definition.
Thanks Alexander Buchkovsky for the fix: it has been merged into 3.6, 3.7 and master branches. Thanks Oleksandr Buchkovskyi for the bug report!
I looked at the Python 2.7 code and it doesn't look to be impacted by this bug.
Modules/_multiprocessing/pipe_connection.c uses ReadFile() and PeekNamedPipe(), but the result type of the two C functions using it is not a PyObject* and conn_recv_string() looks good to me. Moreover, the type of the buflength parameter of conn_recv_string() is size_t, so there is no signed issue.