Hello, Thank you for the SU10 updates that fixed our compilation! We’ve now
worked through the rest of the code and got it to compile. When running, the
WASM gauge is going into a “dirty” state after our variable initialization but
I am not getting any log or indication of why in the console. When I try to
isolate, the issue seems to be related to when we allocate our variable
memory. If I add a “return” randomly somewhere earlier in the code, it works,
but if the function executes fully, the dirty state is applied. The code is
about 1,000 lines of more or less identical function calls with different
strings to setup LVARS and such. I’ve checked for obvious issues like stack
overflows and such to no avail. Additionally, the code is working in P3D and
in our standalone test environment, so I know it’s not a major logical error.
Any help would be appreciated. The latest WASM file is here:
<https://invernyx- my.sharepoint.com/:u:/p/cbiedenkapp/EW97yHTz9rZDoAPS01Hhb1oBSatxa6oQp-
sLa2-5jw3-vQ?e=FwfJhn> The panel.cfg entry to load the gauge is:
Hi, Sorry for the delay An illegal instruction can be caused by a compilation
issue but also by some runtime error (especially in wasm). For instance, a
memory corruption (dereferenced nullptr…) will crash in a c++ environment
but will be “tolerated” in a wasm env and then lead to an illegal instruction.
So, just looking at a part of the code is not sufficient. I will need the
entire source code to determine the real problem Best Regards Maxime / Asobo
We will keep digging - if we’re unable to figure it out, we’d be happy to work
with you via screensharing/remote desktop and try to provide some further
source or clarification.
I just wanted to follow up on this in case others experience the same. In my
case, I had flipped the arguments of a memory copy type operation and was
writing the source to the destination, therefore overwriting read-only memory.
This caused the illegal instruction error I got above, as @Arzop correctly
guessed. If anyone else experiences this, check your code VERY carefully and
isolate sections one by one until you know exactly what causes it and odds
are, you’ll see it (assuming it’s the same type of problem).
Hi @turbofandude, In principle you should have been able to attach to the sim
with a debugger and see which call (here the memcpy) had caused the illegal
instruction. Did you try this method? Didn’t it work? Best regards, Eric /
Asobo
Well, the answer ended up being more complex than that. I did indeed have an
issue with memory copy, but that particular function or line was never blamed
by the debugger for the crash. What actually caused it was my heavy use of a
static vector during initialization. If I store a bunch of lambdas one by one,
that works fine, but if I add a bunch of parameters to a static vector, it
goes into a dirty state with no callstack or further error code. It’s worth
mentioning that the exact same code causing the dirty state works properly
(even in debug mode) in x64 (both in-sim and standalone). It’s almost like I’m
exceeding some limit; if I register just a few events, no dirty state, if I do
them all, dirty state. It’s the weirdest thing.