-
-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Empty error message/traceback for custom Python Actions on Linux #34370
Comments
@espinafre Can you submit a patch with a pull request? |
@gioman I'll clean it up a little and try to do that. A quick grep shows that QgsPythonUtilsImpl::getTraceback() is only used within that class, so removing its locks should do no harm. The same goes for QgsPythonUtilsImpl::runStringUnsafe(), it is not called anywhere else in the QGIS tree, so it should be safe to change its return type (unless this violates some QGIS code of style which I'm not aware of; I'm new to this). |
Moving python traceback collection to within runStringUnsafe() so other threads don't clear the global error status before we have a chance to display it to users.
Moving python traceback collection to within runStringUnsafe() so other threads don't clear the global error status before we have a chance to display it to users.
When trying to port some old custom python2 actions over to QGIS 3/Python 3, we don't have the error messages generated by the Python script; instead, we get the message "traceback.print_exception() failed", along with empty "Python version" and "Python path".
I think this the same issue as #31235 , and this existed since QGIS 2.18 ( https://issues.qgis.org/issues/16923 ); Windows users don't seem to have this problem. I believe that it is caused by the way threading works on Posix systems: in src/python/qgspythonutilsimpl.cpp, the method runString() calls runStringUnsafe(), which acquires then releases the GIL; if runStrtingUnsafe() returns error, runString() calls getTraceback(), which again acquires then releases the GIL, but by that time the error information is lost, the global error objects might have been cleared by some other thread, and all we get is nothingness.
To test this, I've made a very crude patch. It creates a copy of getTraceback() called getTracebackNoLock(), which doesn't attempt to acquire/release the GIL; then, it changes the return type of runStringUnsafe() to QString instead of bool; in case of errors, getTracebackNoLock() gets called there, and its output is returned to runStringUnsafe(), which is finally handled by runString().
This works for me, and I didn't see any unwanted effects, but I haven't tested it extensively.
The text was updated successfully, but these errors were encountered: