micro crashes

[DUOLabs333]

Micro, a text editor written in Go, crashes.

[Sonicadvance1]

Looks like this is a JIT bug around signals.
It works on AArch64+Interpreter.
Crashes on:

• AArch64+JIT
• x86_64+JIT
• x86_64+Interpreter.

[DUOLabs333]

What do you mean Interpreter and JIT? Can you switch between the two modes?

[Sonicadvance1]

Yes. FEX has an interpreter and JIT modes.
Interpreter is slow and used for debugging.
See the FEX_CORE option in the man page.

[DUOLabs333]

I tried this FEX_CORE=irjit Bin/FEXBash, but it just crashed with

erminate called after throwing an instance of 'std::invalid_argument'
  what():  stoi
Aborted (core dumped)

[Sonicadvance1]

Oops, you're right. Looks like we aren't handling textual arguments through environment variables correctly at the moment.
FEX_CORE=1 will be equivalent to irjit
FEX_CORE=0 will be equivalant to irint

[DUOLabs333]

With irint, it doesn't immediately crash, but it doesn't work either, ending with the same error.

[Sonicadvance1]

Took a peek at this.
First thing we need to support is golang's asynchronous preemption. This can be disabled with GODEBUG=asyncpreemptoff=1 but it doesn't workaround the Micro issue.

It then throws an assert in a lockfree stack implementation.

runtime: lfstack.push invalid packing: node=0xffff842b5b40 cnt=0x1 packed=0xffff842b5b400001 -> node=0xffffffff842b5b40
fatal error: lfstack.push

runtime stack:
runtime.throw(0xa66512, 0xc)
        runtime/panic.go:1117 +0x72
runtime.(*lfstack).push(0xf46288, 0xffff842b5b40)
        runtime/lfstack.go:30 +0x14f
runtime.(*spanSetBlockAlloc).free(...)
        runtime/mspanset.go:292
runtime.(*spanSet).reset(0xf3f890)
        runtime/mspanset.go:265 +0x88
runtime.finishsweep_m()
        runtime/mgcsweep.go:145 +0x9c
runtime.gcStart.func1()
        runtime/mgc.go:1381 +0x25
runtime.systemstack(0x0)
        runtime/asm_amd64.s:379 +0x66
runtime.mstart()
        runtime/proc.go:1246

[Sonicadvance1]

Looks like the lfstack panics in my case because of a 48bit VA on my device.
This is a difference on Arm64 versus x86-64 where pointers on x86-64 are expected to sext to 48bit->64bit, while on Arm64 it is expected to zext.
If I steal the top 128TB of address space on Arm64 (Which more closely matches what x86-64 behaviour does) then it works with asyncpreempt disabled.
This will need some more investigation to see what a correct workaround is.

[Sonicadvance1]

golang/go#49405
Bug reported to golang here.