Crashes - Floating Point Exception - Raspberry Pi

[Vegz78]

Describe the bug When compiling for and running @klausw's advanced 3D game, Space Rocks 3D! on a Raspberry Pi, it crashes with the error message "Floating Point Exception".

The game works well in the simulator, and has been tested without any errors on both the PyGamer and the Meowbit, indicating that this probably is an error specific to MakeCode's implementation on the Raspberry Pi and not the game code itself, akin to @nopid's recently fixed error in the Raspberry Pi(RPi) implementation of the namespace setting.

Further supporting that the error is in the compilation itself for the RPi, is the game author's testimony that the game code does not include any floating point operations at all.

I have found that on Posix systems, C++ normally emits Floating Point Exceptions unrelated to floating point operations, and that the exception is thrown rather on conditions of FE_DIVBYZERO, FE_INEXACT, FE_INVALID, FE_OVERFLOW, FE_UNDERFLOW and FE_ALL_EXCEPT.

Further, I have tried debug the game gode by guarding against any obvious divide-by-zero or overflow conditions(tan(90) etc.), to no avail and I have now reached the limits of my competence and depleted all ideas I had for pinpointing the error further. I do not master fully the nuances of integer sizes etc. on the RPi, or where to search for this bug in the pxt compiler code, but all (my) clues seem to lead in this direction.

I really hope the MakeCode team or some bright individuals in the community(like @nopid) can figure out and rectify the difference between the RPi implementation and the implementations for the Web simulator, the PyGamer and the Meowbit, so that this and other future equally advanced 3D games will run also on the RPi!

To Reproduce Steps to reproduce the behavior:

1. Go to https://arcade.makecode.com/beta/?nolocalhost=1&compile=rawELF&hw=rpi#pub:57095-73027-58575-13726 and download as .elf for general RPi or uf2 for the MakeCode Raspberry Pi image. NB!: Very important to download from the beta version of MakeCode Arcade, since the production version is still haunted by the Segmentation Fault error from the RPi implementation of the Settings namespace.
2. Load the game onto the device and run it.
3. Observe black screen and see the Floating Point Exception error

Expected behavior Game running equally well on the RPi as in the web simulator and on the PyGamer and the Meowbit. (In the same spirit of e.g. @jwunderl's "...should probably not crash on hardware (unless it's somehow a valid error, in which case simulator should crash to match hardware :))" in this issue with some similarities.)

Screenshots n/a

Desktop (please complete the following information): See above

Smartphone (please complete the following information): n/a

Additional context n/a

[klausw]

Further supporting that the error is in the compilation itself for the RPi, is the game author's testimony that the game code does not include any floating point operations at all.

Correction, the game does use floating point math. What I meant in our previous discussion was that a majority of the math operations use fixed-point integers. These are still number values in Typescript, but the fixed.ts library uses typing to constrain the values. If I understand it right, the hardware devices use run time type tagging to use integer math operations as long as the values are 30-bit integer numbers.

But In any case, a floating point error during compilation is quite definitely a bug in the MakeCode implementation, that shouldn't happen no matter what type of math the source code is doing.

[Vegz78]

Thanks for clarifying and sorry for misunderstanding and -representing your forum post regarding floating point operations, @klausw!

Anyone has a tip about how to start debugging this and locating the bug in the lower levels and files when everything works on the top level - editor, simulator and several hardware except RPi?

Pretty obvious in retrospective what the error was that @nopid found for the settings namaspace, but an impressive feat nonetheless to actually find it and locate the file(needle in the haystack) in which it resided, in my opinion.

But in this case, even the MakeCode game code is quite large, and it could stem from anywhere in this working code. Then one has to find where and what makes it appear only on RPis...

And how does "everyone" seem to know stuff like that the integer numbers are 30-bit etc.? Apart from the obvious - being better and more experienced coders than I - do you have access to some other special tools to help, like well-commented code, system/code/uml diagrams, serious documentation, custom debuggers, blueprints, whatever? ;-)

The system is just to big and with too many moving parts for me to understand how everything works and fits together as a whole. -At least when there is no obvious link for the failure between working game code and non-working executables(with no c++ source code for this executable).

At least two good news have come from trawling aimlessly through the source code in pursuit of this bug: -I finally stumbled upon what I think might be the reason for the frame buffer not resetting on the RPi(but it does not take a rocket scientist to eventually discover that a screen issue might be related to a file called screen.cpp, but it would have saved a lot of work to find it earlier...) ;-) -I am starting to suspect(makefile) that if this compiles to a general Linux ARM executable, that it might also compile with another compiler to Linux x86_86?... (please correct me if I am wrong)

A bonus is that it is satisfying to know that I still have A LOT to learn for years to come and might never ever find myself in a situation where there's a lack of challenge with both MakeCode and programming in general, that's for sure!

Br, Noob

[Vegz78]

Tried to debug a little by compiling and downloading the game with the?dbg query string in the online editor; https://arcade.makecode.com/beta#editor?hw=rpi&compile=rawELF&dbg=1 (Not sure if ?dbg resembles something similar to the -g compiler flag? But the file size was a little bigger than without.)

Gdb gave the following error on all threads: Backtrace stopped: previous frame identical to this frame (corrupt stack?) And from Stack Overflow searches I could not determine whether the stack actually was corrupt, nor manage any tricks to go further up or down the stack, nor determine if there's something wrong with gdb for arm.

Then, i compiled strace with libunwind and ran it as strace -f -k to attempt a backtrace this way. So far I have not been able to interpret any of the information in a meaningful way to pin-point what triggers this SIGFPE. Maybe someone else finds this issue and could take a look at the output with more trained eyes?: strace.log

Apart from the C++ SIGFPE conditions mentioned above, some people have indicated on forums that they have encountered the floating point exceptions when type casting or assigning an INT to an array of DOUBLE, or something similar.

I don't know, I am a little at loss about how to locate this error effectively(or at all)... ;-)

Any help is appreciated!