[issue9400] multiprocessing.pool.AsyncResult.get() messes up exceptions

Marc Schlaich added the comment: Davin, why isn't just one of the simple one-line patches applied. This would be much more reasonable instead of closing this as won't fix. This is a really ugly bug and it took me hours to find the cause... -- nosy: +schlamar ___

[issue9400] multiprocessing.pool.AsyncResult.get() messes up exceptions

Davin Potts added the comment: Richard already backported the fix for objects which can not be pickled but the second fix (applied to 3.3 in #1692335) would be problematic to similarly backport to 2.7. Because there are reasonable workarounds for this in 2.7, going ahead with marking this clo

[issue9400] multiprocessing.pool.AsyncResult.get() messes up exceptions

Davin Potts added the comment: Reading through issue1692335 provides a sense of the concerns surrounding the patches they applied to the 3.x branches. Attempting to backport those patches to the 2.7 branch involves non-trivial risk, magnified by the now numerous differences between those bran

[issue9400] multiprocessing.pool.AsyncResult.get() messes up exceptions

Davin Potts added the comment: For clarity: * Confirmed, can repro on 2.7.12 on OSX. * Also confirmed that this can not be reproduced on the 3.5 or 3.6 branches. -- versions: -Python 3.5, Python 3.6 ___ Python tracker

[issue9400] multiprocessing.pool.AsyncResult.get() messes up exceptions

Stanislaw Pitucha added the comment: Confirming this on python 2.7.12 on DragonflyBSD -- nosy: +viraptor ___ Python tracker ___ ___ Pyt

[issue9400] multiprocessing.pool.AsyncResult.get() messes up exceptions

Doug Coleman added the comment: Six years later and I'm still running into this exact bug with ``subprocess.CalledProcessError`` on python 2.7.12 when doing a ``multiprocessing.Pool.map`` and trying to catch errors from ``subprocess.check_output``. What's the reason it was never fixed and ba

[issue9400] multiprocessing.pool.AsyncResult.get() messes up exceptions

Changes by Ned Deily : -- nosy: +davin versions: +Python 3.5, Python 3.6 -Python 3.2, Python 3.3, Python 3.4 ___ Python tracker ___ ___

[issue9400] multiprocessing.pool.AsyncResult.get() messes up exceptions

Changes by Martin Dengler : ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/pytho

[issue9400] multiprocessing.pool.AsyncResult.get() messes up exceptions

Changes by Martin Dengler : -- nosy: +mdengler ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pyth

[issue9400] multiprocessing.pool.AsyncResult.get() messes up exceptions

Changes by Torsten Bronger : -- nosy: +bronger ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pytho

[issue9400] multiprocessing.pool.AsyncResult.get() messes up exceptions

Richard Oudkerk added the comment: I am reopening this issue because 26bbff4562a7 only dealt with objects which cannot be pickled. But CalledProcessError instances *can* be pickled: the problem is that the resulting data cannot be unpickled. Note that in Python 3.3 CalledProcessError can be p

[issue9400] multiprocessing.pool.AsyncResult.get() messes up exceptions

Changes by Richard Oudkerk : -- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed ___ Python tracker ___ _

[issue9400] multiprocessing.pool.AsyncResult.get() messes up exceptions

Richard Oudkerk added the comment: I have backported the fix for issue #9244 to 2.7. This should fix the hang and produce a traceback containing a representation of the original error. -- ___ Python tracker _

[issue9400] multiprocessing.pool.AsyncResult.get() messes up exceptions

Roundup Robot added the comment: New changeset 26bbff4562a7 by Richard Oudkerk in branch '2.7': Issue #9400: Partial backport of fix for #9244 http://hg.python.org/cpython/rev/26bbff4562a7 -- nosy: +python-dev ___ Python tracker

[issue9400] multiprocessing.pool.AsyncResult.get() messes up exceptions

Richard Oudkerk added the comment: There are plenty of other "bad" exception classes apart from CalledProcessError, including TimeoutExpired in the same file. In fact I suspect this is true of the majority of the exception classes in the stdlib which override __init__. So I am not sure how

[issue9400] multiprocessing.pool.AsyncResult.get() messes up exceptions

Changes by Antoine Pitrou : -- nosy: +sbt ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org

[issue9400] multiprocessing.pool.AsyncResult.get() messes up exceptions

Daniel Blanchard added the comment: The patch appears to fix the issue, so is there any chance of this actually getting accepted this time? It seems bizarre that such a simple bug that has been on the books for almost two years now can't get a patch accepted. -- _

[issue9400] multiprocessing.pool.AsyncResult.get() messes up exceptions

Amaury Forgeot d'Arc added the comment: Here is another patch, with test. -- nosy: +amaury.forgeotdarc stage: test needed -> patch review Added file: http://bugs.python.org/file25111/picklable_process_exception.patch ___ Python tracker

[issue9400] multiprocessing.pool.AsyncResult.get() messes up exceptions

Daniel Blanchard added the comment: I believe I'm still encountering this issue in 2.7: Exception in thread Thread-3: Traceback (most recent call last): File "/opt/python/2.7/lib/python2.7/threading.py", line 552, in __bootstrap_inner self.run() File "/opt/python/2.7/lib/python2.7/thr

[issue9400] multiprocessing.pool.AsyncResult.get() messes up exceptions

Ray.Allen added the comment: This is because when an subprocess.CalledProcessError is raised, the CalledProcessError instance is picked through a socket and then read by "parent" process, but in fact CalledProcessError instances cannot be picked correctly. Because CalledProcessError extends P

[issue9400] multiprocessing.pool.AsyncResult.get() messes up exceptions

Nikolaus Rath added the comment: @ray: Try it with the following dummy dcon program: $ cat dcon #!/bin/sh exit 127 (and change the path to dcon in bug.py accordingly). -- ___ Python tracker

[issue9400] multiprocessing.pool.AsyncResult.get() messes up exceptions

Jesse Noller added the comment: @ray - you probably don't have the "dcon" binary on your path. bug.py calls a subprocess call. -- ___ Python tracker ___

[issue9400] multiprocessing.pool.AsyncResult.get() messes up exceptions

Ray.Allen added the comment: I got "OSError: [Errno 2] No such file or directory" instead of TypeError when running the "bug.py", did I miss something? -- nosy: +ysj.ray ___ Python tracker

[issue9400] multiprocessing.pool.AsyncResult.get() messes up exceptions

Changes by R. David Murray : -- nosy: +jnoller stage: -> unit test needed ___ Python tracker ___ ___ Python-bugs-list mailing list Uns

[issue9400] multiprocessing.pool.AsyncResult.get() messes up exceptions

New submission from Nikolaus Rath : The attached test program calls apply_async with a function that will raise CalledProcessError. However, when result.get() is called, it raises a TypeError and the program hangs: $ ./bug.py ERROR:root:ops Traceback (most recent call last): File "./bug.py",