search

OpenSmalltalk / opensmalltalk-vm

Cross-platform virtual machine for Squeak, Pharo, Cuis, and Newspeak.
http://opensmalltalk.org/
Other
547 stars 110 forks source link

Crash in macOS ARM upon disabling primitive mixed-arithmetic handling #667

Closed cperezabo closed 7 months ago

cperezabo commented 8 months ago

Hi folks,

First some context:

I've tried to disable primitive mixed-arithmetic 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
eliotmiranda commented 8 months ago

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: @.***>

cperezabo commented 8 months ago

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. 🫣

cperezabo commented 8 months ago

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.

cperezabo commented 8 months ago

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?

OpenSmalltalk-Bot commented 8 months ago

Hi Cristián,

On Wed, Nov 15, 2023 at 2:50 PM Cristián Pérez @.***> 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: @.***>

-- ,,,^..^,,, best, Eliot

stormwatch commented 8 months ago

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?

eliotmiranda commented 8 months ago

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

cperezabo commented 8 months ago

So who is in charge of doing OpenSmalltalk VM releases? We should talk to that person, shouldn't we?

marceltaeumel commented 8 months ago

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.

cperezabo commented 8 months ago

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?

marceltaeumel commented 8 months ago

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/

marceltaeumel commented 7 months ago

See

marceltaeumel commented 7 months ago

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.

cperezabo commented 7 months ago

Yes, we are going to use the parameter 75 instead.