[Vm-dev] OSVM | Strange segfaults in macos64ARMv8 -f builds ...

Eliot Miranda eliot.miranda at gmail.com
Sat Apr 2 02:34:18 UTC 2022


Hi Marcel,

On Fri, Apr 1, 2022 at 2:37 AM Marcel Taeumel <marcel.taeumel at hpi.de> wrote:

> Hi Eliot --
>
> The segfaults might be related to #checkForEventsMayContextSwitch:.
> Currently, it directly pumps all events, which now include some display
> events. But before that, it tries to go some compacted-code path:
>
> checkForEventsMayContextSwitch: bool
>    ...
>    self checkCogCompiledCodeCompactionCalledFor.
>    ...
>    self ioProcessEvents.
>    ...
>
> Now, #ioProcessEvents may end up reading the displayBits. Yes, those are
> pinned ... and "commenceCogCompiledCodeCompaction" seems to always show up
> at the C stack backtrace ...
>

The last thing in the crash dump is **CompactCode**, which shows that the
VM is in code compaction.  It just so happens that code compaction is
almost always invoked from checkForEventsMayContextSwitch:, so that isn't
interesting.  Why the VM is crashing in commenceCogCompiledCodeCompaction
is the question. Looking at the function in lldb it seems that the crash is
on return from compactCogCompiledCode.  The stack trace points us to
compactCogCompiledCode + 204:

2   squeak                              0x0000000100a0cd1c sigsegv + 240
3   libsystem_platform.dylib            0x0000000195d82c44 _sigtramp + 56
4   squeak                              0x00000001009bfb04
*commenceCogCompiledCodeCompaction
+ 204*
5   squeak                              0x000000010098a7e8
checkForEventsMayContextSwitch + 104
6   squeak                              0x000000010098ed24 ceStackOverflow
+ 136

disassembling in lldb we see:

(lldb) dis -n commenceCogCompiledCodeCompaction
...
Squeak[0x10004caa0] <+196>: str    x9, [x8, #0x8]
Squeak[0x10004caa4] <+200>: bl     0x100056e7c               ;
compactCogCompiledCode at cogitARMv8.c:10187
Squeak[0x10004caa8] <+204>: adrp   x8, 251
Squeak[0x10004caac] <+208>: str    xzr, [x8, #0xb00]
Squeak[0x10004cab0] <+212>: nop
Squeak[0x10004cab4] <+216>: str    xzr, [x8, #0xaf8]
Squeak[0x10004cab8] <+220>: ldr    x8, [x20, #0xdc8]
...

So it looks like the crash is actually the store
Squeak[0x10004caac] <+208>: str    xzr, [x8, #0xb00]
and perhaps x8 has been corrupted.  It has the value 6, which isn't going
to work for the store.  Why x8 is getting changed I don't know.  More
investigation is needed :-)


> Best,
> Marcel
>
> Am 31.03.2022 18:23:26 schrieb Marcel Taeumel <marcel.taeumel at hpi.de>:
> Hi Eliot --
>
> I am trying to understand some sporadic segfaults while fixing some things
> around -core-graphics and -metal backends:
> https://github.com/marceltaeumel/opensmalltalk-vm/tree/marceltaeumel/high-resolution-fix
>
> The current changes for -core-graphics and -metal backends in this branch
> put more "pressure" on the applications event loop. In that area, I could
> tweak vmIOProcessEvents a little bit to get less segfaults. I think it was
> some old Carbon-related code. However, the sporadic segfaults remain. At
> one point, I could just try to open a new MVC or Morphic project and the VM
> would segfault. :-/ Sometimes it takes a little bit longer.
>
> Please find attached an exemplary crash report.
>
> I have not yet managed to reproduce that segfault in an X86_64 builds
> (i.e., macos64x64) ... Am I doing this or is there some bug in the ARM JIT?
> :-/
>
> If you try out this branch, make sure to have a recent Squeak Trunk and
> do-it:
> "WorldState disableDeferredUpdates: true"
>
> Otherwise you will see flickering and not see dragging within Morphic.
>
> Best,
> Marcel
>
>

-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20220401/c5575d81/attachment-0001.html>


More information about the Vm-dev mailing list