Termux/aarch64: Segfaults at 97% build progress

[athraxkobal]

Cloning and doing "make regular" works as intended, but building luvi tends to display segfaults at 97% or 98%
The build process runs fine until 97%, where "jitted_tmp/src/lua/init.lua_luvi_generated.o" and
"jitted_tmp/src/lua/luvibundle.lua_luvi_generated.o" both segfault.
At 98%, "jitted_tmp/src/lua/init.lua_luvi_generated.o" segfaults again and "jitted_tmp/deps/lpeg/re.lua_luvi_generated.o" joins the party.

Screenshot: https://cdn.discordapp.com/attachments/598878518570385420/687727043022290992/Screenshot_20200312-1419541.png

This error occasionally pops up around here:
deps/luv/luajit: ./jit/bcsave.lua:0: attempt to compare two table values

[drveoj]

Having the same issue. Anyone looked into this yet? Really want to be able to run luvit on my Raspberry PIs :D

[thonkinator]

thanks to Nameless (aka truemedian) for this.
just run these two lines and wait for it to compile:
export PREFIX=.
curl -L https://github.com/truemedian/luvit-bin/raw/main/install.sh | sh

[Bilal2453]

Just to clear stuff out. The build did indeed work on a aarch64 using that script, not necessary fixed, might just mean your exact setup had a less chance of encountering the same segfault, specially in your case it wasn't a Termux setup. Will have to do more investigating on this.

[squeek502]

luvit-bin uses make regular-asm while the OP is using make regular. Can anyone confirm if make regular-asm avoids the segfault?

[athraxkobal]

luvit-bin uses make regular-asm while the OP is using make regular. Can anyone confirm if make regular-asm avoids the segfault?

Tried just now, no.

[truemedian]

This is making a lot less sense than it should, could it possibly be a Termux bug?

[Bilal2453]

This is making a lot less sense than it should, could it possibly be a Termux bug?

that is a high chance indeed, but according to @drveoj, this did happen with their Raspberry as well as Termux.

Tried just now, no.

@athraxkobal Can you try the instructions in this reply? if you haven't already

export PREFIX=.
curl -L https://github.com/truemedian/luvit-bin/raw/main/install.sh | sh

[athraxkobal]

@Bilal2453 Fails the exact same way after looking at the install.log

[drveoj]

@Bilal2453 Fails the exact same way after looking at the install.log

Happy to pitch in on the Raspberry side if I can help...

[truemedian]

I've debugged this farther than I wanted to, it appears to be a bug in aarch64 luajit. If anyone has an actual aarch64 machine and the knowledge, we might want to submit a bug report to luajit about this.

[drveoj]

Just to confirm (for the absence of doubt) this doesn't work on PI(4)

Linux ember 5.4.0-1030-raspi #33-Ubuntu SMP PREEMPT Wed Feb 24 11:20:11 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux

curl -L https://github.com/truemedian/luvit-bin/raw/main/install.sh | sh yeilds:

[ 97%] Building Luajitted /home/joev/bot/luvi.d/src/lua/luvibundle.lua: /home/joev/bot/luvi.d/build/jitted_tmp/src/lua/luvibundle.lua_luvi_generated.o
make[2]: *** [CMakeFiles/luvi.dir/build.make:73: jitted_tmp/src/lua/luvibundle.lua_luvi_generated.o] Segmentation fault (core dumped)
make[2]: *** Waiting for unfinished jobs....
make[2]: *** [CMakeFiles/luvi.dir/build.make:63: jitted_tmp/src/lua/init.lua_luvi_generated.o] Segmentation fault (core dumped)
make[2]: *** [CMakeFiles/luvi.dir/build.make:78: jitted_tmp/deps/lpeg/re.lua_luvi_generated.o] Segmentation fault (core dumped)
make[2]: *** [CMakeFiles/luvi.dir/build.make:68: jitted_tmp/src/lua/luvipath.lua_luvi_generated.o] Segmentation fault (core dumped)
make[1]: *** [CMakeFiles/Makefile2:190: CMakeFiles/luvi.dir/all] Error 2
make: *** [Makefile:130: all] Error 2

[wozeparrot]

I bisected luajit to this bad commit: 3143b218946395834f0bfef741061ac6ef3f5b56.

Not really sure how to proceed from here.

[Bilal2453]

Can indeed confirm it compiles just fine on aarch64 using make regular on the commit before 3143b218, 78f5f1cef. Thanks @wozeparrot, now good luck knowing how that commit broke things, it is quite a large one.

Edit: Do note that both latest LuaJIT and the problematic commit compile just fine under aarch64 with default make flags.

[wozeparrot]

Managed to get luvi to compile with commit 3143b218.

Seemingly the issue with commit 3143b218 is that when building luajit, luv isn't passing the correct flags to DASM to set the endianness.

By patching the luajit.cmake file in luv to add -DENDIAN_LE to DASM_FLAGS will allow luvi to build with no issues on aarch64.

[squeek502]

By patching the luajit.cmake file in luv to add -DENDIAN_LE to DASM_FLAGS will allow luvi to build with no issues on aarch64.

Could TestBigEndian/CMAKE_C_BYTE_ORDER be used to determine when to pass this flag? Or should it always be passed?

[truemedian]

A quick glance at Luajit's makefile shows that luvit's cmake file for building luajit is out of sync.

luvit vs luajit. I'll take a look at this in more detail so that this same issue doesn't pop back up on us and submit a PR to luv.

[wozeparrot]

By patching the luajit.cmake file in luv to add -DENDIAN_LE to DASM_FLAGS will allow luvi to build with no issues on aarch64.

Could TestBigEndian/CMAKE_C_BYTE_ORDER be used to determine when to pass this flag? Or should it always be passed?

You should pass -DENDIAN_LE for little endian and -DENDIAN_BE for big endian. So this should be tested for and handled accordingly.

[truemedian]

If endianness does actually happen to be the only issue here, then luvit/luv#570 should fix this issue once and for all.

However, in the interest of keeping the rest of the cmake file still functional on older versions of luajit I only added the few missing things. In the future it probably needs to be reworked or redone to be more in line with the current luajit makefile.