Hi i am using python multiprocessing module and the problem is when i get an error from a code that has been executed in another thread, the Traceback is only pointing to multiprocessing/pool.py", line 520 instead of the line number of what caused the error exactly.
Traceback (most recent call last):
File "analyzer.py", line 196, in <module>
for ret in pool.imap(ProcessRow, rows):
File "/usr/lib64/python2.6/multiprocessing/pool.py", line 520, in next
raise value
TypeError: unsupported operand type(s) for +: 'NoneType' and 'str'
so line 196 in analyzer.py is when i call for ret in pool.imap(ProcessRow, rows):
so it's completely not helpful....Any advice ?
The error is raised from ProcessRow() or some function called by it (why is your function CamelCaseUpper?).
You are not getting a proper stack trace, because the exception is actually pickled from the subprocess (hence the name of the module: multiprocessing) your code is executing in and is then raised again in the manager process. Hence the stack trace shows up as if it was local (while it is actually an exception raised in the subprocess).
The preferred way of dealing with this seems to be to catch the exception in the forked of code and printing a proper stacktrace from there.
Related
When running Python script that makes use of Cython and C++ and an unhandled exception occurs console output doesn't contain any useful information:
collecting ... Fatal Python error: Aborted
Current thread 0x00007f0c1f7ec000 (most recent call first):
File ".../test_program.py", line 29 in test_eval_simple
File ".../test_program.py", line 31 in <module>
File ".../venv/lib/python3.10/site-packages/_pytest/assertion/rewrite.py", line 168 in exec_module
...
However if I attach C++ debugger and run the same script an exception information is being printed out which makes debugging much easier:
terminate called after throwing an instance of 'af::exception'
what(): ArrayFire Exception (Invalid input size:203):
In function af::dim4 getOutDims(const af::dim4&, const af::dim4&, bool)
In file src/backend/ArrayInfo.cpp:173
Invalid dimension for argument 1
Expected: ldims == rdims
In function af::array af::operator/(const af::array&, const af::array&)
Is it possible to instruct Cython/Python to produce a more meaningful message and print out C++ exception information by default?
I'm working on a convoluted FOSS project that utilizes GTK+3. When a flow graph is generated and attempted to run it, it generates the following error:
'Page' object has no attribute 'get_flow_graph'
There are 30 different files that have the generic "...object has no attribute..." exception listed in the code, and there are 4 files that call the function get_flow_graph().
So what I want to figure out is which of the 30 files that generate that particular error message is being executed, and preferably which of the 4 files with the function are causing the error in the first place.
I'm trying to use Python's traceback module to figure out where, specifically, the exception is being generated. I think I figured out the file that is calling the function that ultimately errors out, but I can't seem to get the traceback module to provide much more.
For example, if I wrap the function like this:
try:
fg = self.page.get_flow_graph()
except Exception:
traceback.print_exc()
then I just get
File "<redacted>", line 66, in _popen
fg = self.page.get_flow_graph()
AttributeError: 'Page' object has no attribute 'get_flow_graph'
'Page' object has no attribute 'get_proc'
as the output. So I get the original exception but a new get_proc error that doesn't help me but is obviously associated with trying to use traceback.
Maybe I'm not putting the trace in the correct file/location, or maybe I'm asking too much, but how should I write it to figure out the actual stack trace for the original AttributeError?
Does using
except AttributeError as e:
print(e.__traceback__.tb_lineno)
print(e.__traceback__.tb_frame)
instead, helps you further? (really asking, not being ironic)
I am trying to understand a traceback error that I am receiving. See below.
Traceback (most recent call last):
File "test.py", line 291, in test_cache_in_function
self.assertTrue("sunset" in testfilestr,"Testing that the sunset request was cached")
AssertionError: Testing that the sunset request was cached
Does the above error mean that "sunset" should not be in the cached file?
A point about nomenclature. You are getting a AssertionError. The error is printed along with the traceback, which indicates the sequence of calls that led to that error.
In your particular case, it looks like the error is caused because the assertion made by self.assertTrue(...) came out False. You are asserting that the string "sunset" is in testfilestr, but it is not. Probably because it is in the cache file instead.
The second argument to assertTrue is a message, which you see as the message to the AssertionError. This argument is optional, and is usually used to clarify the error beyond the obvious default message, which would be something to the effect of "sunset" in testfilestr is False, expected True.
I tried to add a new node following the example but:
myitems = ruamel.yaml.load(inp, ruamel.yaml.RoundTripLoader)
myitems['abc'].append('test')
gives me an error:
Traceback (most recent call last):
File "item_updater.py", line 148, in <module>
myitems['wohnung'].append('test')
AttributeError: 'CommentedMap' object has no attribute 'append'
I am using ruamel.yaml v0.13.7
What am I doing wrong?
Your error doesn't come from the example you indicated, as in the inp of the example there is no wohnung that shows up in your error.
You probably forgot a - somewhere:
wohnung:
a: 1
instead of:
wohnung:
- a: 1
only on the latter you can append using myitems['wohnung'].append('test').
The example works, but without showing your real YAML input it is difficult to see what is the exact cause of your error.
I am trying to simulate a repeat-until loop in Theano:
def method_a(arguments):
...
return result, theano.scan.until(t.eq(a,b))
I encountered the following strange behaviour. Let b be a constant. Whenever a is a constant, everything works fine. However, when a is a scalar, I get an error related to optimisation:
ERROR (theano.gof.opt): SeqOptimizer apply <theano.gof.opt.EquilibriumOptimizer object at 0x110d0d8d0>
ERROR (theano.gof.opt): Traceback:
ERROR (theano.gof.opt): Traceback (most recent call last):
File "[...]/lib/python2.7/site-packages/theano/gof/opt.py", line 196, in apply
sub_prof = optimizer.optimize(fgraph)
File "[...]/python2.7/site-packages/theano/gof/opt.py", line 82, in optimize
ret = self.apply(fgraph, *args, **kwargs)
File "[...]/python2.7/site-packages/theano/gof/opt.py", line 1665, in apply
gopt.apply(fgraph)
File "[...]/python2.7/site-packages/theano/scan_module/scan_opt.py", line 1300, in apply
if self.belongs_to_set(nd, subset):
File "[...]/python2.7/site-packages/theano/scan_module/scan_opt.py", line 1286, in belongs_to_set
rep.op.inputs)
File "[...]/python2.7/site-packages/theano/scan_module/scan_utils.py", line 452, in equal_computations
dx.type.dtype == dy.type.dtype and
AttributeError: 'NoneTypeT' object has no attribute 'dtype'
I'd appreciate if someone could help me understand the error. I'm assuming the AttributeError doesn't refer to a or b, because I can print their dtype and see that they do have one. Other than that, I can't make any sense out of it.
[Edit] This is not a fatal error. The code runs normally and the process finishes with exit code 0. It looks like Theano is trying to optimise the graph and fails to do so, which doesn't really impact the program.
The traceback indicate that in the function equal_compuations(), we didn't cover all case, when doing some comparison.
I have a PR with a fix for it here:
https://github.com/Theano/Theano/pull/1928
thanks for the report.
Your [edit] section, indicate me that you cut some of the errors message. If this happear during optimization with a warning, it mean an optimization was just skipped. It is possible that the optimization just don't apply, but it could be possible that with the fix, now the optimization apply. If that is the case, there could be some speed up with the fix.