Hello, As per the subject, using gauge_calculator_code_precompile() in a WASM
module compiled with /clang:-O3 can corrupt variables/memory currently on the
stack. This also happens with “-O2” level, but not with “-O1” or “-O0” (in
either Release or Debug builds). I have also tried each optimization level
with and w/out “Fast WASM compilation” option checked, no apparent difference
there. I have attached a minimal reproducible example WASM module. It runs the
same calculator code string twice, once as-is, and once by first pre-compiling
it and then running the bytecode. In the function with the
gauge_calculator_code_precompile() call, there is a dummy data structure
created on the stack. The struct has one simple char array member with some
text. The contents of the struct are printed out before and after
gauge_calculator_code_precompile() runs (both as as string and as a hex byte
dump). Here is an example of the relevant output which shows the issue:
Running execute_calculator_code with "(A:FUEL TOTAL CAPACITY, liters)" and pre-compile: true
Test Data Pre-Compilation: "Test"; 54:65:73:74:00;
Compiled "(A:FUEL TOTAL CAPACITY, liters)" to bytecode with size 27: 01:1B:00:00:06:00:56:02:00:01:14:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
Test Data Post-Compilation: "??"; 03:02:00:00:00;
execute_calculator_code() returned: 336.902, 32758, "336.9"
(You may also wonder why it returns ‘32758’ as the integer value instead of
‘337’… that’s a good question and I have no idea… my actual WASM module
doesn’t do that, with any of the optimization options, nor can I figure out
what is causing it to do so here.) Attached is a VS2022 project with the
module code, and a subfolder with with MSFS project (xml, etc). The VS
projects has configured Release-O3, Release-O1, and Debug (no O level
specified) type builds. There is a pre-built (with O3) .wasm in the package
source folder, so one could just load up the project in MSFS and build it
(w/out VS). The tests are run automatically upon module init and output is
sent to MSFS console. There are comments in the code with some of my findings.
The issue is not trivial to recreate, and only manifests under certain
circumstances (as mentioned in code comments). However this is how memory
corruption issues are… the fact that it’s not always obvious doesn’t mean
it’s not always happening. Furthermore, I have to wonder what else we’re not
seeing. Please let me know if there is something wrong with the code somehow,
or if I can provide any other info or testing. FWIW, my MSFS crashes pretty
consistently after running these tests a few times. BTW, I’ve also taken this
opportunity to show how gauge_calculator_code_precompile() doesn’t work with
formatted strings meant for format_calculator_string() function. Which I had
brought up [here](https://devsupport.flightsimulator.com/questions/9513/gauge-
calculator-code-precompile-with-code-meant-f.html) but got no response on.
Thank you, -Max MP-WASM-Module-
Test.zip