[OpenSmalltalk/opensmalltalk-vm] Crash in macOS ARM upon disabling primitive mixed-arithmetics handling (Issue #667)
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-arithmetics handling by the two following ways, getting the same results.
```smalltalk Smalltalk vmParameterAt: 48 put: 64 ```
```smalltalk Smalltalk vmParameterAt: 75 put: false ```
Here 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 Cristián, how does one reproduce the crash?_,,,^..^,,,_ (phone)On Nov 14, 2023, at 8:27 AM, Cristián Pérez ***@***.***> wrote: 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-arithmetics handling by the two following ways, getting the same results. Smalltalk vmParameterAt: 48 put: 64 Smalltalk vmParameterAt: 75 put: false Here 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
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
Hi, have you seen the content of your message? It's all broken. 🫣
On the other hand, I exposed the two ways to switch the flag in my 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)
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-... 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 (you can see it [here](https://github.com/cperezabo/opensmalltalk-vm/actions/runs/6883323331), 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](https://github.com/OpenSmalltalk/opensmalltalk-vm/actions/runs/6515002351) (from last month) and it works as expected. Do you know when are you going to release it officially?
Hi Cristián,
On Wed, Nov 15, 2023 at 2:50 PM Cristián Pérez notifications@github.com wrote:
It worked (you can see it here, 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.
That's great news.
Do you know when are you going to release it officially?
Well, I don't manage the Cuis VM releases. It's up to the Cuis community. I would recommend that you keep up to date choosing a fairly new VM buolt for Squeak. But the Cuis community might want to build its own VMs, ensuring that the VM is packaged correctly (calls itself Cuis, has the desired set of plugins, etc). Talk it over with Juan Vuletich.
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: OpenSmalltalk/opensmalltalk-vm/issues/667/1813391350@github.com
Hi Eliot, Cristián,
On 11/16/2023 4:21 PM, Eliot Miranda wrote:
Hi Cristián,
On Wed, Nov 15, 2023 at 2:50 PM Cristián Pérez <notifications@github.com mailto:notifications@github.com> wrote: ...
Do you know when are you going to release it officially?Well, I don't manage the Cuis VM releases. It's up to the Cuis community. I would recommend that you keep up to date choosing a fairly new VM buolt for Squeak. But the Cuis community might want to build its own VMs, ensuring that the VM is packaged correctly (calls itself Cuis, has the desired set of plugins, etc). Talk it over with Juan Vuletich.
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: <OpenSmalltalk/opensmalltalk-vm/issues/667/1813391350@github.com>-- _,,,^..^,,,_ best, Eliot
So far we haven't seen a real need to build separate VMs, as using recent builds from https://github.com/OpenSmalltalk/opensmalltalk-vm has been perfectly fine, especially because they include VectorEnginePlugin as an internal plugin.
We may start to build "branded" VMs perhaps removing some plugins at some moment, though.
Thanks!
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?
On Thu, Nov 16, 2023 at 4:05 PM Ezequiel Birman ***@***.***> wrote:
Hello @eliotmiranda https://github.com/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?
Good question. I don't maintain these. would ask that those who do would organize a release around commit 5cc4fa5afc0120c48206c5668aacef7ae7307802
Author: Eliot Miranda ***@***.***> Date: Thu Jun 8 11:23:14 2023 -0700
Accept the -eventtrace option on unix & windows.
_,,,^..^,,,_ best, Eliot
So who is in charge of doing opensmalltalk VM releases? We need to talk with that person...
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, 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. The more people help, the faster we can release a new artifact. Thanks! :-)
See - https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202311211431 - https://lists.squeakfoundation.org/archives/list/vm-dev@lists.squeakfoundati...
Closed #667 as completed.
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.
vm-dev@lists.squeakfoundation.org
-
Cristián Pérez -
Eliot Miranda -
Eliot Miranda
-
Ezequiel Birman
-
Juan Vuletich -
Marcel Taeumel