Open joaoponceleao opened 1 year ago
SrNetoChan
commented
1 year ago @joaoponceleao Yes, exactly. Are there any know results of this error? Besides the error itself? If not, I would let the error be. There's no point in disable it just to omit the error message IMHO.
joaoponceleao
commented
1 year ago Problem is the error pops up a window that needs to be clicked to continue loading qgis. Many will fail to see the window pop up and just wait... This behaviour would need to be disabled for this particular error.
SrNetoChan
commented
1 year ago Well, I am -0 to apply this patch n our conda builds.
If others feel it's important we can do it. Truth is that most folks will not miss this functionality, but we should keep this ticket open to keep an eye on it. Even if it's not a conda issue (which is a relief)
gillins
commented
1 year ago So no one knows what causes the error? Sorry, I'm just trying to catch up here.
SrNetoChan
commented
1 year ago No. It only happens in macos arm, not in x64. We were the first to build in MacOS arm, but seems that the same error appear in mac os arm64 using homebrew, so it's not a conda thing. besides, it seems that the folder have write permissions so...
gillins
commented
1 year ago Hmm would be good to have a QGIS developer comment on this. Or someone who knows the finer details of OSX security....
justinbb
commented
1 year ago Another couple of observations. Although the call to faulthandler.enable() fails, the traceback file is nevertheless created (empty). As @Firefishy notes, faulthandler.is_enabled() returns true but nothing is ever written to the file. (To test the faulthandler by provoking a python crash, see the Example at the end of https://docs.python.org/3/library/faulthandler.html)
If, in the QGIS python console, I do
faulthandler.disable()
faulthandler.enable(file=qgis.utils.__qgis_fault_handler_file)the call succeeds without any error messages. If I then provoke a python crash, the traceback file does contain the expected information about the crash.
All this to say that the problem seems to be with the timing of the attempt to open the file, or some other state-related problem that is resolved by the time QGIS has finished starting up.
I wonder if delaying the initialization of python would help any (or just break many other things). I wonder if the problem might have something to do with app startup procedures that are handled by Qt calling Mac system routines, and if the whole thing might just go away with the impending upgrade to Qt 6.
nilason
commented
11 months ago FYI, same issue on ARM machines with MacPorts too https://trac.macports.org/ticket/67844.
gillins
commented
2 months ago Has this been fixed upstream?
justinbb
commented
2 months ago No, the bug https://github.com/qgis/QGIS/issues/52987 is still open with no recent activity.
Solution to issue cannot be found in the documentation.
Issue
Hi,
The latest qgis for mac arm gives a faulthandler error on startup:
Haven't tested to see how it affects QGIS.
Related ( I can split this into a separate issue): I also noticed some errors due to missing python modules which usually come included with QGIS due to a number of plugins requiring them: matplotlib, pandas, scipy. Which brings me to the following error messages in the qgis log on startup:
I imagine this is due to a plugin trying to install scipy. QGIS allows plugins to install modules when they're missing. Naturally, we can install ourselves in the conda env, but something should be done about the above errors: I don't see why a plugin would use the system pip to install rather than QGIS's own pip (in this case the conda env).
Finally, getting the following errors, presumably due to current settings from the official package. Would be nice to fix those without having to change the QGIS preferences that are used by the official packages too.
Installed packages
Environment info