Crashes(segfault?) - exists property - settings namespace - Raspberry Pi

[Vegz78]

Describe the bug
When using the settings.exists("string") property from the settings namespace inside an if statement, the MakeCode Arcade program terminates/crashes (with Segmentation fault?) when compiled for and run natively as .elf file on a Raspberry Pi.

More precisely, the program terminates on the settings.exists("scores") property only if this settings file does not exist yet, but it works if the file already exists.

To Reproduce
Steps to reproduce the behavior:

1. Go to 'https://arcade.makecode.com/#pub:_dH1asvKAaUF8?nolocalhost=1&compile=rawELF&hw=rpi'
2. Click on 'Download' to download .elf file
3. chmod 755 arcade-blocks-leaderboard_ns.elf
4. Execute game with ./arcade-blocks-leaderboard_ns.elf or using McAirpos
5. After entering the first leader board entry, see error:
   [1442173983] GC block 16376b @ 0x20000000
   [ 0] runtime starting, pid=8664...
   [ 6] FB: DRM emulated at 1920x1080 1920x1080 bpp=32
   [ 12] FB: DRM emulated at 1920x1080 1920x1080 bpp=32 7680
   [ 16] init keys
   [ 16] read config: /sd/arcade.cfg
   [ 21] SCAN_CODES=/dev/input/event4
   [ 25] BTN_LEFT=30
   [ 28] BTN_RIGHT=32
   [ 32] BTN_UP=17
   [ 35] BTN_DOWN=31
   [ 39] BTN_A=29
   [ 42] BTN_B=42
   [ 48] BTN_LEFT2=105
   [ 51] BTN_RIGHT2=106
   [ 54] BTN_UP2=103
   [ 57] BTN_DOWN2=108
   [ 60] BTN_A2=100
   [ 63] BTN_B2=57
   [ 66] BTN_RESET=59
   [ 69] BTN_EXIT=1
   [ 73] BTN_MENU=60
   [ 76] config done
   [ 86] sx=8 sy=9 ox=320 oy=0 32=1
   [ 89] fbuf=0xb5c29000 sz:8294400
   [ 101] loop
   [ 336] GC block 16376b @ 0x20004000
   [ 343] GC block 16376b @ 0x20008000
   [ 1336] PCM name: 'default'
   [ 1342] PCM state: PREPARED
   [ 4358] GC block 16376b @ 0x2000c000
   (Segmentation fault) (Not sure if this last is from the game file itself when crashing or from the launcher)
   
   

Expected behavior
The MakeCode Arcade program should continue execution when encountering the settings.exists("string") property.

Screenshots

Desktop (please complete the following information):

• OS'es run on: [Raspberry Pi OS Jessi, Buster and Buster, on RPi 3B, RPi 3B and RPi4 B, respectively]
• Browsers compiled and downloaded from: [various Chrome based browsers on MacOS and updated Win10]

Additional context
The problem seems to be with the settings namespace itself in pxt-arcade and NOT with the settings extension

It works inside the web simulator in the MakeCode Arcade editor on all browsers and OS'es.

The above none-working example is based on @riknoll's example from the MakeCode forum which also is NOT working:
https://arcade.makecode.com/#pub:46238-89332-69341-89890?nolocalhost=1&compile=rawELF&hw=rpi

Here is a solution with a work-around instead of the settings.exists("scores") property, and which IS working:
https://arcade.makecode.com/#pub:_816E0X0brPog?nolocalhost=1&compile=rawELF&hw=rpi

It might also be worth mentioning(and maybe somewhat related?), that when using the settings namespace functions, one often has to run/execute the games twice, to allow for all the settings files to be written properly in the game_file.elf.data folder, which seldom works fully/correctly on the first run no matter which permissions are set, as described here:
Vegz78/McAirpos#14 (comment)
microsoft/pxt-settings-blocks#2 (comment)

[Vegz78]

FYI, I have recently discovered that the segmentation fault was due to a bug in my own McAirpos launcher code.

However, it still applies(if not fixed by MS in the meantime?...), when running a MakeCode Arcade game natively(.elf) directly and without any external launchers or wrappers on Raspberry Pi OS, that the game crashes/exits when using the if settings.exists("variablename") check without the above described workaround of checking if "variablename" is undefined instead.

[nopid]

I observed the same problem with settings.exists("foobar") on RPi 0 with UF2 for Linux (slightly modified for GamePi20: https://github.com/nopid/uf2-gamepi20).

Looking at the implementation of settings with files (https://github.com/microsoft/pxt-common-packages/blob/5af0bab37ec48a8f47578f4638ce22604511aef0/libs/settings---files/settings.cpp#L137-L141), it looks like exists fails to check the return value of fopen. The behavior of fclose(NULL) is not specified and with GNU libc it is known to generate segfault.

I submitted a PR to fix the problem: microsoft/pxt-common-packages#1345

[Vegz78]

Nice work, both for finding and fixing this bug, and with the uf2-gamepi20 mod, @nopid!!!

When will this fix to the common-packages be updated to pxt-arcade and arcade.makecode.com/beta, so we can test easily from the web, @pelikhan?

[nopid]

Thanks @Vegz78. The fix was enough to run tilecode on a GamePi20.

If you want to test the updated common-package before official release, you can use a local server. I do it with Docker: https://github.com/nopid/docker-pxt-arcade The current nopid/pxt-arcade image on Docker Hub is compiled with pxt-arcade v1.8.25, pxt v7.4.27 and pxt-common-packages master (with the fix).

As for using uf2-linux with GamePi20, I now have something decent enough, I put a binary release for convenience here: https://github.com/nopid/uf2-gamepi20/releases/tag/alpha1 I still have some random games crashes from time to time that I need to investigate.

[Vegz78]

@nopid and @abchatra/@pelikhan!

Just tested the settings namespace on https://arcade.makecode.com/beta, which, as of today, was updated to pxt target v1.9.12, including @nopid's fix. -Worked like a charm running as a .elf file on my Raspberry Pi!

Nice and thanks!

[Vegz78]

Sorry to bother you again, @nopid.

But would you, as a fellow Raspberry Pi fan and a lot sharper in C++ than me, happen to know why this amazing 3D game gives a Floating point exception natively compiledon my Raspberry Pis?:
https://arcade.makecode.com/beta/?nolocalhost=1&compile=rawELF&hw=rpi#pub:57095-73027-58575-13726

Works very well in the web simulator.

Original source:
https://forum.makecode.com/t/space-rocks-3d/6334/70
(You have to compile it in beta, since the main arcade.makecode.com is still plagued by the segmantation fault you fixed for the settings namespace here...)