Segmentation Fault on ARM MacOS #186
Comments
|
Can you post the results of |
murrayrm
changed the title
|
Here is log: |
|
That all looks OK. Can you run |
|
|
I'm guessing that the problem may be with slycot, since the control package itself is just pure python. Can you try running Note: this may screw up your conda environment, so if you are using this environment for other things, you might want to create a new one first. |
|
Actually, another thing to try first: see if |
|
Yes! |
|
OK, we should move this issue over to the slycot issues list so the group there can have a look. I'll do that and post the info from here. |
|
@SeyedMohamadMoosavi FYI, I have moved this to slycot. @bnavigator @roryyorke Any ideas about what might be happening on MacOS Ventura? |
|
Probably another problem with the cross-compilation for macOS arm on the conda-forge/slycot-feedstock. Maybe @isuruf or someone else from @conda-forge/help-osx-arm64 has an idea how to debug this. |
|
conda-forge/simpleitk-feedstock#27 mentions our struggle with the slycot-feedstock and has yet another fix. |
|
@SeyedMohamadMoosavi do you get a similar segmentation fault when you install an older slycot version with |
|
yes, I get the same error. |
|
Can you please try the new slycot 0.5.3 to be published on conda-forge shortly? Also, please make sure to install everything from conda-forge. No mixins of packages from "normal" anaconda. |
|
I get the same error. |
bnavigator
changed the title
|
Without an M1 or M2 at hand, it is hard to debug these errors. Do we have reports of functioning Mac on Arm installs? @murrayrm, @sawyerbfuller, you have Macs right? @SeyedMohamadMoosavi, @bdube-jpl If you are able to collect a crash-report with debugger symbols that would be highly appreciated. Also, one might try to compile Slycot locally on the Mac and see if that is different. See https://github.com/python-control/Slycot#using-the-conda-recipe for instructions. |
|
This would be a command to create a conda environent with strictly conda-forge packages, no packages from main: |
|
I was able to install slycot from conda-forge on an M1 mac, but running MacOS 12.6.2 (Monterey). So it might be something in Ventura. |
|
There is also still a possible difference between Conda/Python for native Arm and with Rosetta, if I am not mistaken? |
|
Here's some, hopefully, complete info Create a minimum environment with conda, if it matters, I have At the moment, that grabs I can post the transitive dependency versions too, if that is interesting. All of them come from conda-forge, none from the main channel, or any others.
The conda installer is available in native form, and with the If anyone else wishes to reproduce, I had to follow this page to enable core dumps. This will reproduce, as long as your username is bdube and you use controlcrash as the environment name: apparently /bin can't make core dumps, so I used the full path to python: The core file is here -- I don't think I can attach a 3.6GB file to github. If there is an issue, please let me know and I'll upload it elsewhere. Please share it within an intranet, if developers share a network -- I'll have to pay for egress if the file gets downloaded too many times (too many ~=50/mo). Self building, I cloned slycot, which gets I'm not sure if the setup/pyproject/etc files are broken, but pip goes rogue (as it is wont to do, sigh): pip should not have tried to download/install anything; numpy, etc, are already in site-packages for the python install (via conda). I'm very familiar with pure python packaging (etc), but I'm not sure how to proceed from here with the fortran component. If someone can provide a bit of help, I am happy to continue. |
|
Hi @bdube-jpl, thanks for the extensive info! I am fetching the core right now. Hopefully I can analyze it later this week. Regarding pip: The new standard way is to build wheels in an isolated environment which needs all the build requirements as wheels. There is the Did you try the Slycot/.github/workflows/slycot-build-and-test.yml Lines 150 to 171 in 773c893 Also there is https://github.com/conda-forge/slycot-feedstock/blob/main/recipe/build.sh for a reference of tweaks |
|
The actual compilation worked (I assume), but there is some setup issue still. I can try the conda recipe if you'd like, too |
|
Yes please try the conda recipe. Looks like you have encountered a bug in either Ping @henryiii |
|
I fixed something lightly related to this recently, I'm guessing the above is with the most recent version of scikit-build? Don't think it would fix exactly this (why is it not getting any information about the platform tag? I expect all packaging starts breaking if that's empty - in fact yes, this is crashing before it even gets to scikit-build's customizations, so my recent fix for valid platform tags wouldn't even get hit). I guess there's a small chance it's setting this based on an observed I'm guessing you are trying to cross-compile, and are setting up an invalid environment? Conda-forge's environment setup is complex. By hand, it's much easier to build a cross-compiled wheel (such as via cibuildwheel). Conda is a hacked-together mess of scripts that kind of needs perfect setup to build (like on CI). |
|
Thanks for the inpit @henryiii, I fully agree with your assessment that conda is too brittle. @bdube-jpl is actually trying to natively compile on ARM as opposed to cross-compile like conda-forge does. Either way it is hard to get a functioning compiled package. |
|
I think it may be an issue in skbuild. I have v0.16.6. Here's a tree of The exception thrown by wheel is, I don't actually see anything that has a trailing period, Now, conda build.. |
|
Oh my, that stupid conda resolver. Could you try to replace Line 30 in 773c893 |
|
What does |
|
sysconfig: e: I am on ventura 13.1, so there is probably a separate bug in sysconfig with Ventura... With the modified numpy in meta.yml, the package does build and install properly, but results in the segfault on import. The fortran compile complained about some out-of-bounds array access, so maybe that is the fundamental issue (why it seems to work in general and not on arm could easily be a difference in UB between compilers). ~line 1354 in the log. It may also be Numpy ABI incompatibility between 1.16 (I think it built with this anyway?) and my 1.24.1. Usually Numpy self-detects that and prints a warning on import that the size of the array object has changed between compile and runtime though. The attached is the log from conda-build |
|
The out of bounds is a false positive error message, see #111. Thanks for trying! So we can conclude that it is not problem with the cross-compilation. Now back to the segfault, can you run gdb or a Mac equivalent for it? |
|
yes |
|
Follow up on this thread: I recently upgraded to Ventura with M2 and was able to get python-control and Slycot all working with arm64. Are others on this thread still having problems? If not, we can probably close this one off. |
|
No further feedback since. Closing. |
Installed the package using conda in a clean conda environment on MacOS Ventura M1 Pro Chip.
conda install -c conda-forge control slycotHowever, I get segmentation fault after importing control:
import controloutput is:
The text was updated successfully, but these errors were encountered: