faulthandler error arm mac #301
Comments
|
@SrNetoChan is this the same error you are seeing? |
|
Yes @gillins the first one is the one I saw, I couldn't investigate more to understand what it implies. The rest of the errors described by @joaoponceleao are sort of expected. We have no builds with saga or grass (but installing by your own would probably fix it) and about plugins... Well, they are not designed to work with conda. You can install the package using conda, or you can install pip using conda. That way any installation from plugins should use that pip. I would prefer the first option. |
|
@SrNetoChan just tested this on |
|
I have no idea. I have limited access to the Mac OS M1 machine, so I didn't get to try much more and see what is failing. There's that error an a bunch of warnings, but for general purpose, everything seems to work fine. |
|
Ah fair enough, I don't have access to OSX either - will leave it for someone with more OSX experience to investigate and resolve. Good to hear it works fine though! |
|
I suspect it may be more to do with the OS (Ventura) and its new permissions system rather than the arm architecture. I can try installing it under rosetta to see but best would be someone with an M1 testing it under the previous Monterey OS. |
|
My system configuration: macBook pro M1 Pro 16 GB SO Ventura 13.0.1 confirm error @joaoponceleao : Notifications from terminal : If you run the installation in an environment with intel packages (rosetta), everything is fine without any error reports. Note the difference in performance in (ms). So I would not say that the problems could be related to the Ventura operating system. |
|
qgis3_283_env In rosetta2 environment we have: |
|
I don't know enough of Mac system, but if you use an environment with roseta, then it is not using arm architecture. Right? |
|
Apart from that error, have you noticed anything that does not work when running QGIS on arm? |
The qgis3_283_env environment created is arm, while the one named qgis3_283_ros is in rosetta. I have exposed both configurations. |
I am testing it, for now I had to remove some non-compatible plugins. |
|
If possible, report which plugins and the errors here, so we can track down what can be the problem (s). Thanks! |
|
It seems the issue is taking place during python startup here: |
|
I want to create a new clean environment and reinstall everything. I will update you. |
|
I created a new environment and reinstalled QGIS 3.283. The error is reported again. An error occurred during execution of following code: Traceback (most recent call last): Python version: QGIS version: Python path: If you have any suggestions I will proceed with testing. I confirm that in Rosetta environment, no error. |
Interesting - thanks for running the tests. Is this something we need to report upstream? |
I doubt it, since it works in Rosetta. I would look at other gui applications installed through conda to see if they had to make any adjustments for arm. This error does not show up if you launch the QGIS binary inside the conda environment folder directly from the finder, for instance. But you get other issues since the conda env was not activated. |
|
What I don't understand is that with Rosetta 2 the permissions required to access or write to the file specified as fault_handler_file are overridden or bypassed? Which in the ARM architecture is not possible? |
@gillins Maybe we should report this upstream. In the terminal the error (operation not permitted) occurs during Btw. Faulthandler is enabled if you open up the python console after qgis starts. |
|
But there is a check for |
|
This is taking place on a ubuntu docker image running on the m1 too apparently. See: camptocamp/docker-qgis-server#590 |
|
This seems a different error from above? |
|
@gillins My laptop is Apple Silicon. Is there anything you'd like me check out? |
|
Thanks @joaoponceleao. Would be good to print the values of |
|
Sorry @gillins. I'm afraid that might be beyond my abilities. I'm used to debugging qgis plugins in the terminal, but not qgis itself (and would rather not have to build it from source). On a, possibly related note(?), python uses an env variable for faulthandler (PYTHONFAULTHANDLER). Starting conda's arm qgis with that env set to anything, will cause a fatal error:
Doing the same with the x86 oficial release (launching it from terminal) causes no errors. |
|
I'm afraid I know very little about OSX so I guess we are stuck for now. Can you find anything about this behaviour changing in recent OSX versions? |
|
Next step would be to try running this in the qgis python console: And see if the permission exception is raised. Also testing this in a standalone (non qgis) python session. That will determine if the fault lies with qgis or conda/upstream python. |
|
Thanks @nyalldawson |
|
I will try the latter as soon as possible in a borrowed machine |
|
This is how the log file name is generated:
What's that return in the qgis python console? |
Publishing debug packages, in a similar fashion we do dev packages, from a branch and publishing in a "qgis_debug" is OK. We never formalized that but it would be something similar to the cfep-05 instructions. |
|
I have installed qgis 3.30 with with python 3.11 using a brand new mamba-forge installation on a Mac arm64. I was not able to reproduce the error. Running the code suggested by @nyalldawson I got no errors either.
|
|
@nyalldawson the return for File exists, folder is writable. Official QGIS binary chooses the same folder to write to. |
|
@joaoponceleao shouldn't make a difference, but what installer did you use? conda? Mamba? What version? |
|
@SrNetoChan I was curious to find out if something was wrong with my conda, so I did a new installation. Issue persists with a fresh install. Mamba qgis environment gives: |
|
@SrNetoChan you've seen this error with an older version of QGIS on OSX arm64 right? |
|
@gillins yes I did. So I am now wondering what changed in my installation. I will try miniconda instead of mamba-forge and I will try older versions of qgis. My mamba-forge installation was not from homebrew, but using the follwing command: |
|
@SrNetoChan that type of installation shouldn’t make a difference, but perhaps there is something going on in my zshrc. I’ll try with a minimal profile. |
Please noticed that an recent contact of my from twitter also reported this error, and I not sure he has any very customized terminal. |
|
@SrNetoChan Yes, I do not have a custom terminal in fact you can consider my install on clean MacBook Air m1 as until now I only used it to consume/stream videos mainly |
|
This looks similar: qgis/QGIS#52987 |
|
I get the error on startup... Some debugged via QGIS python console: |
|
Patch to remove the ?faulty? |
|
That seems to simply remove the functionality. No? I wouldn't use it. |
|
@SrNetoChan That repo does not use conda. It updates the homebrew build of the official binaries to arm64. If he did this, it would imply that it's not a conda issue but one of the dependencies no? |
|
@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. |
|
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. |
|
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) |
|
So no one knows what causes the error? Sorry, I'm just trying to catch up here. |
|
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... |
|
Hmm would be good to have a QGIS developer comment on this. Or someone who knows the finer details of OSX security.... |
|
Another couple of observations. Although the call to If, in the QGIS python console, I do 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. |
|
FYI, same issue on ARM machines with MacPorts too https://trac.macports.org/ticket/67844. |
|
Has this been fixed upstream? |
|
No, the bug qgis/QGIS#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
The text was updated successfully, but these errors were encountered: