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.

Title: get method of multiprocessing.pool.Async should return full traceback
Type: enhancement Stage: resolved
Components: Library (Lib) Versions: Python 3.4
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: fmitha, python-dev, sbt, slinkp
Priority: normal Keywords: patch

Created on 2012-01-19 20:46 by fmitha, last changed 2022-04-11 14:57 by admin. This issue is now closed.

File name Uploaded Description Edit
pool-traceback.patch sbt, 2013-05-02 15:48 review
Messages (6)
msg151651 - (view) Author: Faheem Mitha (fmitha) Date: 2012-01-19 20:46
The documentation in


"""class multiprocessing.pool.AsyncResult¶
The class of the result returned by Pool.apply_async() and Pool.map_async().

Return the result when it arrives. If timeout is not None and the result does not arrive within timeout seconds then multiprocessing.TimeoutError is raised. If the remote call raised an exception then that exception will be reraised by get()."""

Consider the example code


from multiprocessing import Pool

def go():
    print 1
    raise Exception("foobar")
    print 2

p = Pool()
x = p.apply_async(go)


The traceback from this is

Traceback (most recent call last):
  File "<stdin>", line 10, in <module>
  File "/usr/lib/python2.6/multiprocessing/", line 422, in get
    raise self._value
Exception: foobar

As is clear in this example, this is not a full traceback - it only shows the traceback to the line where get is located and gives no further information. This is the case in all the other places I have used get. It seems to me that it *should* return the full traceback, which may contain important information missing in such a partial one. I don't know whether one would call this a feature request or a bug report. Maybe there is some technical reason why this is not possible, but I can't think of one.
msg187247 - (view) Author: Richard Oudkerk (sbt) * (Python committer) Date: 2013-04-18 13:43
Pickling an exception (assuming it works) does not capture the traceback.  Doing so would be difficult/impossible since the traceback refers to a linked list of frames, and each frame has references to lots of other stuff like the code object, the global dict, local dict, builtin dict, ...  I certainly do not know how to make traceback objects pickle compatible.

But you could wrap any exception raised by your function in another exception whose representation contains a formatted traceback of the original exception.  E.g.

class WrapException(Exception):
    def __init__(self):
        exc_type, exc_value, exc_tb = sys.exc_info()
        self.exception = exc_value
        self.formatted = ''.join(traceback.format_exception(exc_type, exc_value, exc_tb))
    def __str__(self):
        return '%s\nOriginal traceback:\n%s' % (Exception.__str__(self), self.formatted)

def go():
    except Exception:
        raise WrapException()

Then raising an unpickled WrapException instance gives the original traceback

>>> try: go()
... except Exception as e: exc = e
>>> raise pickle.loads(pickle.dumps(exc))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
Original traceback:
Traceback (most recent call last):
  File "<stdin>", line 3, in go
ZeroDivisionError: integer division or modulo by zero
msg187818 - (view) Author: Richard Oudkerk (sbt) * (Python committer) Date: 2013-04-25 20:31
It might be possible to come up with a hack so that when the exception is unpickled in the main process it gets a secondary exception chained to it using __cause__ or __context__ whose stringification contains the stringification of the original traceback.
msg188276 - (view) Author: Richard Oudkerk (sbt) * (Python committer) Date: 2013-05-02 15:48
Attached is a patch for 3.4 which uses the __cause__ hack to embed the remote traceback in the local traceback.  It will not work for 2.x though.

>>> import multiprocessing, subprocess
>>> with multiprocessing.Pool() as p: p.apply(subprocess.Popen, (1,))
Traceback (most recent call last):
  File "/home/oudkerk/Repos/py-default/Lib/multiprocessing/", line 114, in worker
    result = (True, func(*args, **kwds))
  File "/home/oudkerk/Repos/py-default/Lib/", line 838, in __init__
    restore_signals, start_new_session)
  File "/home/oudkerk/Repos/py-default/Lib/", line 1317, in _execute_child
    args = list(args)
TypeError: 'int' object is not iterable

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/oudkerk/Repos/py-default/Lib/multiprocessing/", line 245, in apply
    return self.apply_async(func, args, kwds).get()
  File "/home/oudkerk/Repos/py-default/Lib/multiprocessing/", line 588, in get
    raise self._value
TypeError: 'int' object is not iterable
msg188513 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2013-05-06 11:25
New changeset a2928dd2fde4 by Richard Oudkerk in branch 'default':
Correct issue number for c4f92b597074 in Misc/NEWS from #13813 to #13831
msg188567 - (view) Author: Richard Oudkerk (sbt) * (Python committer) Date: 2013-05-06 18:16
The relevant changeset was c4f92b597074, but I wrote the wrong issue number in the commit message and Misc/NEWS.
Date User Action Args
2022-04-11 14:57:25adminsetgithub: 58039
2013-05-06 18:16:59sbtsetmessages: + msg188567
2013-05-06 11:40:27sbtsetstatus: open -> closed
resolution: fixed
stage: resolved
2013-05-06 11:25:58python-devsetnosy: + python-dev
messages: + msg188513
2013-05-02 15:48:12sbtsetfiles: + pool-traceback.patch
keywords: + patch
messages: + msg188276
2013-04-25 20:31:57sbtsetmessages: + msg187818
versions: + Python 3.4, - Python 2.6, Python 3.3
2013-04-18 13:43:51sbtsetnosy: + sbt
messages: + msg187247
2013-04-17 19:48:01slinkpsetversions: + Python 3.3
2013-04-17 19:45:54slinkpsetnosy: + slinkp
2012-01-19 20:46:39fmithacreate