Traceback when using multiprocessing, less than helpful?
rosuav at gmail.com
Thu Nov 21 18:24:33 CET 2013
On Fri, Nov 22, 2013 at 4:01 AM, John Ladasky
<john_ladasky at sbcglobal.net> wrote:
> Here is the end of the traceback, starting with the last line of my code: "result = pool.map(evaluate, bundles)". After that, I'm into Python itself.
> File ".../evaluate.py", line 81, in evaluate
> result = pool.map(evaluate, bundles)
> File "/usr/lib/python3.3/multiprocessing/pool.py", line 228, in map
> return self._map_async(func, iterable, mapstar, chunksize).get()
> File "/usr/lib/python3.3/multiprocessing/pool.py", line 564, in get
> raise self._value
> ValueError: operands could not be broadcast together with shapes (1,3) (4)
> Notice that no line of numpy appears in the traceback? Still, there are three things that make me think that this error is coming from numpy.
Hmm. This looks like a possible need for the 'raise from' syntax. I
just checked multiprocessing/pool.py from 3.4 alpha, and it has much
what you're seeing there, in the definition of AsyncResult (of which
MapResult is a subclass). The question is, though, how well does the
information traverse the process boundary?
More information about the Python-list