Crash in macOS ARM upon disabling primitive mixed-arithmetic handling
cperezabo opened this issue · comments
Hi folks,
First some context:
- I'm working on an M1 Pro, macOS 14.1, no Rosetta, fully native.
- This was first discovered on Cuis but I reproduced it in Squeak as well.
- I'm using the latest release of the VM from this repository while using Cuis. For Squeak I'm using the latest AIO release.
I've tried to disable primitive mixed-arithmetic handling by the two following ways, getting the same results.
Smalltalk vmParameterAt: 48 put: 64Smalltalk vmParameterAt: 75 put: falseHere is the trace I get when it crashes
C stack backtrace & registers:
x0 0x104908657 x1 0x10f7c1b70 x2 0x0 x3 0x104940010
x4 0x1b588bb3 x5 0x10492e940 x6 0x11345d358 x7 0x1126efcd8
x8 0x259 x9 0x10f795690 x10 0x10f7c1b00 x11 0x112200000
x12 0x50 x13 0x50 x14 0x10493f000 x15 0x10f7c1b00
x16 0x10492be50 x17 0x7 x18 0x10493fff0 x19 0x0
x20 0x0 x21 0x113389900 x22 0x10491f000 x23 0x10491f000
x24 0x10491f000 x25 0x10491f000 x26 0x10491f000 x27 0x10492bd38
x29 0x0 fp 0x10491f000 lr 0x16b598db0 sp 0x104815aa0
0 ??? 0x000000010f795690 0x0 + 4554577552
1 Squeak 0x0000000104898c9c reportStackState + 840
2 Squeak 0x0000000104899020 sigsegv + 240
3 libsystem_platform.dylib 0x0000000186b33a24 _sigtramp + 56
4 Squeak 0x0000000104815aa0 returntoExecutive + 128
5 Squeak 0x000000010481b0e8 ceSendsupertonumArgs + 1084
6 ??? 0x000000010f794178 0x0 + 4554572152
7 Squeak 0x0000000104809268 interpret + 660
8 Squeak 0x000000010489a488 -[sqSqueakMainApplication runSqueak] + 424
9 Foundation 0x0000000187d99aac __NSFirePerformWithOrder + 296
10 CoreFoundation 0x0000000186be10a0 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 36
11 CoreFoundation 0x0000000186be0f8c __CFRunLoopDoObservers + 532
12 CoreFoundation 0x0000000186be05bc __CFRunLoopRun + 776
13 CoreFoundation 0x0000000186bdfc5c CFRunLoopRunSpecific + 608
14 HIToolbox 0x0000000191159448 RunCurrentEventLoopInMode + 292
15 HIToolbox 0x00000001911590d8 ReceiveNextEventCommon + 220
16 HIToolbox 0x0000000191158fdc _BlockUntilNextEventMatchingListInModeWithFilter + 76
17 AppKit 0x000000018a3bac54 _DPSNextEvent + 660
18 AppKit 0x000000018ab90ebc -[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 716
19 AppKit 0x000000018a3ae100 -[NSApplication run] + 476
20 AppKit 0x000000018a3853cc NSApplicationMain + 880
21 dyld 0x00000001867890e0 start + 2360
Hi, I exposed the two ways to switch the flag in the previous message, you just need to get an M1/2/3 machine without Rosetta installed, run any of those commands and boom 💥.
For the sake of simplicity I'd recommend you to download the AIO version of Squeak which has the fat-binary for macOS, because the standalone ARM binary of the vm is not working by itself (this should be a different issue)
PS: Have you seen the content of your message? it's all broken and duplicating the original message. 🫣
Hi @eliotmiranda, I built the VM on my Mac and everything worked as expected with no changes.
I think the problem comes from the runner version you are using to build the macOS VM. It's macos-11, which is not native ARM.
That could explain why the "ARM" version of the VM won't start on my machine (with no Rosetta installed). macOS says it's corrupted, but, for some reason it works if it's part of the universal fat-binary 🤷🏻♂️
The runner that supports real ARM processor is macos-13 - https://github.blog/2023-10-02-introducing-the-new-apple-silicon-powered-m1-macos-larger-runner-for-github-actions/
I forked the repo and I'm currently running the build on the new runner to see if it works, so I'll give you news about it when it finishes.
It worked, here is the build, but it's not because of the runner. The official VM release is too old (June 2022)!. That's why it doesn't even work using the VM that comes with Squeak AIO.
I've tried the build from your last build (from last month) and it works as expected.
Do you know when are you going to release it officially?
Hello @eliotmiranda
Cuis could use newer VM builds as you suggest, but why is the last release listed in https://github.com/OpenSmalltalk/opensmalltalk-vm/releases dated 2022-06-02?
So who is in charge of doing OpenSmalltalk VM releases? We should talk to that person, shouldn't we?
Releasing somewhat tested and stable VMs requires some work. The nightly builds work fine in general. We will make a next VM release for the next Squeak release as those usually happen close together. We use Squeak as a testbed for VM issues.
Here are the latest builds: https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/latest-build
If Cuis happens to be in dire need of a new official OSVM release, I am sure that we can work something out.
Hi @marceltaeumel, of course we understand what you say! And as you say, Cuis needs a new stable release of the VM to work well in macOS ARM, since Cuis sets the vm parameter mentioned at the startup, making the VM crash.
How can we collaborate?
Hi @cperezabo -- Just look for a call-for-testing in the next couple of days on vm-dev[1]. The more people help, the faster we can release a new artifact. Thanks! :-)
[1] https://lists.squeakfoundation.org/mailman3/lists/vm-dev.lists.squeakfoundation.org/
Aaaaand:
Smalltalk vmParameterAt: 48 put: 64
This would clear many other flags stored in the image header such as method-flagging, process-preemption-yields, and new-style finalization. So, better only flip that single bit 6 here. Or use the boolean parameter 75 as you suggested.
Yes, we are going to use the parameter 75 instead.