-
-
Notifications
You must be signed in to change notification settings - Fork 1.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
Segmentation Fault under Rosetta emulation, Node.js 14, M1 Max, macOS Monterey #3048
Comments
What's the output of running Do you see the same problem if you checkout the |
If I switch to main branch, do
|
Thanks, it looks like you're using Rosetta emulation. What's the output of running |
|
Please can you |
Ok install succeeded, but tests results in a segmentation fault too:
|
Thanks, this looks like it might be a problem with Rosetta emulation specific to the M1 Max. Are you able to install a native Node.js 16, with |
I switched to 16 with process.arch of arm64, and tests pass fine. |
Thanks for confirming. I know many people successfully run sharp under Rosetta emulation on M1 devices, so this is likely to be a new bug/feature in Apple's Rosetta emulation specific to either the M1 Max CPU and/or macOS Monterey. To be able to help further, I'll need a backtrace of the crash using a minimal test case. Run |
I can't even install gdb, brew install gdb has no bottle found, and trying to build from source is a problem too. Is there an alternative? |
You might be able to use |
my minimal-test.js
|
Thanks, that looks like a fairly generic It might be worth ensuring you're using the latest Rosetta emulator, perhaps via a forced uninstall/reinstall. If you're still having this problem, a smaller, more focussed test case that uses only sharp would be really useful to help pinpoint exactly which format/operation might be causing this. From your comments above this might be based on the following test case: Lines 93 to 102 in 1ff84b2
|
In a minimal mocha test suite file, like below:
I put in a return statement in that for loop so it just runs once. So in total, sharp will only run twice: once in first test, and the 1st time in the for loop before its forced to exit. I think run Weirdness here:
I eventually pinpointed the problem line:
which brought me to:
The image was test/fixtures/fixtures.inputJpg320x240. What's odd is that in my original test file, it's used as an input for the first test too and runs fine. This points to the interpolator being the culprit, or at least one of them: |
Great research, thank you for doing this. Nearest neighbour interpolation is relatively simple - it pretty much copies memory, so perhaps there's an optimisation being used for this in the x64 code that the M1 Max Rosetta emulator can't handle? These binaries are built using clang on macOS Catalina. I guess the next step might be to create a tiny test case that can reproduce this, ideally as a separate, minimalist repo, then ask Apple (with their annual revenue of USD365,000,000,000) to investigate. On a related note, I've added Rosetta emulation to the CI running on an M1 Mac mini (Big Sur) via commit 3b370b6 to try to catch similar problems - see https://github.com/lovell/sharp/runs/4920230048?check_suite_focus=true for a successful run. |
The thing I don't got is why both tests need to run in order for the second one to fail |
I guess it's possible that JIT optimisation has recompiled some bytecode by the second invocation, which if so adds more fuel to the fire of this being a bug in the Rosetta emulator. |
Are you able to test with v0.30.1 as it contains a fix for a possible memory problem that we uncovered by running with the "wrong" libgobject - see #3082 There's also a somewhat-related issue that mentions M1 Pro, Rosetta and gobject here - Homebrew/homebrew-core#88801 |
looks like it worked, all tests are passing! |
Brilliant, thanks for confirming. |
Related issue:
ionic-team/capacitor-assets#272
Sharp is causing a segmentation fault when converting images on my Mac.
I have macOS Monterey, on an M1 Max chip.
When I download sharp locally and run
npm test
, I get:It's not random, the same tests fail each time.
The text was updated successfully, but these errors were encountered: