plane icon Welcome to Microsoft Flight Simulator’s SDK Q&A Platform!

You have questions regarding the SDK? DevMode Tools? SimConnect? You would like to submit an idea for future improvements, seek help or exchange knowledge? You’re in the right place.


Please take a moment to read the platform’s guidelines before you get started!


question

max.paperno avatar image
max.paperno asked MachSystems commented

Stack corruption with gauge_calculator_code_precompile() and '/clang:-O3'

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 but got no response on.

Thank you,
-Max


MP-WASM-Module-Test.zip

wasmc++
10 |10000

Up to 5 attachments (including images) can be used with a maximum of 4.8 MiB each and 23.8 MiB total.

EPellissier avatar image
EPellissier answered EPellissier commented

Hi @max.paperno,

Thanks for reporting the issue. Although we couldn't reproduce it on our end, we have identified two problems in the code that could indeed lead to such a stack corruption. They have now been fixed and the fix should be available in the next update. As a side note, I don't think it is really linked to the new "/clang:-O3" option.

Regarding the issue between gauge_calculator_code_precompile and format_calculator_string, this is still under investigation - I'll reply in the original topic.

Best regards,

Eric / Asobo

2 comments
10 |10000

Up to 5 attachments (including images) can be used with a maximum of 4.8 MiB each and 23.8 MiB total.

max.paperno avatar image max.paperno commented ·

Hi again Eric, and thanks for the quick turnaround! Great news that you managed to find something from this.

Do you think the "O3" just brought whatever issue already existed to light? I hadn't really considered that possibility, but that would make sense as well.

Was the issue you found specific to `gauge_calculator_code_precompile()`? (Just wondering if it will be "safe to go in the water" once that is fixed, paranoid of other hidden issues.)

Thanks again
-Max

0 Likes 0 ·
EPellissier avatar image EPellissier ♦♦ max.paperno commented ·

Both gauge_calculator_code_precompile and execute_calculator_code could be affected by this issue: an internal function in the sim was storing a 64-bit value at an address which should only store 32-bit values, changing the next 32-bit value in the process (this is related to the fact that WASM in MSFS is a 32-bit platform).

It is unsure at this stage if optimization played a role in the issue but we'll have a look at the assembly produced with different optimization levels as soon as we can.

Best regards,

Eric / Asobo

1 Like 1 ·
MachSystems avatar image
MachSystems answered MachSystems commented

I met the same issue. The gauge_calculator_code_precompile function call corrupt the 4 bytes just before the compiled PCSTRINGZ variable.


Maybe try this can help:


UINT32 _dummy; // Add a unused 4 bytes variable to hold the stack corruption.

PCSTRINGZ compiled;

...

gauge_calculator_code_precompile(...);

2 comments
10 |10000

Up to 5 attachments (including images) can be used with a maximum of 4.8 MiB each and 23.8 MiB total.

EPellissier avatar image EPellissier ♦♦ commented ·
Which version of MSFS are you using?

The fix will be available in SU11 and I believe it should already be included in the SU11 flighting.

Best regards,

Eric / Asobo

0 Likes 0 ·
MachSystems avatar image MachSystems EPellissier ♦♦ commented ·

Thank you Eric. The official latest release 1.27.21.0, haven't participate in the Beta program. It's not big problem but very hard to locate, cost me nearly a full day.

Looking forward to the fixes. Thank you again.

1 Like 1 ·

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

Up to 5 attachments (including images) can be used with a maximum of 19.1 MiB each and 23.8 MiB total.