Closed 1uc closed 2 weeks ago
✔️ febdf6d570c8821ba5eb1e0069810328f561990e -> Azure artifacts URL
Logfiles from GitLab pipeline #217749 (:no_entry:) have been uploaded here!
Status and direct links:
✔️ f8eb6ef6d8c9b2017eb47ec749582209cbaca667 -> Azure artifacts URL
Issues
15 New issues
0 Accepted issues
Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code
✔️ 4f3b5ab91e08b833616a56b188134f25f8caf3a8 -> Azure artifacts URL
Logfiles from GitLab pipeline #217821 (:no_entry:) have been uploaded here!
Status and direct links:
This PR introduces a wrapper of all C function that are registered with Python. The wrapper catches all exceptions, and converts them to Python exceptions, then it returns a value signaling an error.
The reason we want to convert C++ exceptions to Python errors, is that when a C++ exception occurs, it terminates the program in a manner that makes it very hard to determine which Python code triggered the exception. For example PDB will crash before being able to print a backtrace. Similarly the regular Python exception mechanism will not run; and not print the usual helpful backtraces. Using GDB for example reveals that
PyEval_EvalCode
callsgetattro
forrng_StochKv3
, but it doesn't help understand what happened in the Python layer, i.e. what lead to callinggetattro
.With the wrapper we get the following output for #2783:
It contains the C++ error message
generic_data_handle bla bla bla
but also the Python backtrace. We get the same behaviour in the more complex reproducer, which allowed us to instantly spot that the bug was indeed in NRN not in the user library. We can now use PDB for debugging:If we want to debug the C++ layer we use GDB as before on
x86_64/special
.