This is about my CRJ and the issue seems to be related to compiling it with newer SDKs (I tested 23.1 and 24.3) - none of these crashes occurs in the released version. To get rid of the problems listed below, I updated the project settings to those of a freshly created one (24.3 SDK) and also brought the gauge callbacks and display handling to a more current standard - without any success though.
What happens is that I’m getting a lot of WASM crashes, mostly during and after “build all”, but also in other situations (Loading a PNG from a network get response using nvgCreateImageMem or when SimConnect_CallDispatch is called). The call stack is not the same all the time, but it always ends up in a function called dlfree(). The problem occurs in debug mode more often than in release mode.
I was able to fix a number of occurances by avoiding the use of new/malloc/delete/free but others, I can’t fix because there’s no pointer involved on my side.
To be honest, I have no clue what’s going on. If anyone at Asobo wishes to look into this, I can upload project and source code (and a bunch of screenshots of the different call stacks when those crashes occur) for you to look at.
Other ideas are very welcome too, of course
I suspect a memory corruption somewhere, BuildAll will call the kill callback, so it will free a lot of memory, increasing the chance to free a corrupt chunk of memory, resulting into invalid read.
I’ve tried to repro without success for the moment. Can you give us more detail on a particular repro, which option to activate in the EFB, where to navigate in the gauges, or any information you’ll find useful.
I have to thank for your time, not the other way round
I tried the whole thing again with the same code that I uploaded for you (not the actual current project). The first 2 or 3 “Build Alls” worked fine, but then I ran into crashes after almost every build again (not the one that came up before compiling the WASM into a DLL though).
I recorded the steps on video and uploaded it to the Onedrive folder where the project, source and screenshots are also located (Microsoft OneDrive).
The filename is CRJ_WASM_Crash.mp4
I agree with your opinion that it’s likely some sort of memory corruption. I noticed (for the first time) that the crashes started after logging into Navigraph (EFB → Options Page 2). As soon as I established the link to their servers, the CRJ checks the authentification and connection on each start. This is a new situation that I wasn’t aware of. May be I forgot to free data that I got from fsNetworkHttpRequestGet() or something similar. I will check this first thing tomorrow (Thursday) morning and then get back to you.
After yesterday’s finding that the crashes are somehow related to the Navigraph interface and with it, a lot of fsNetworkHttpRequestGetData() calls, I went over the whole part of the code, which is quite extensive for METAR/TAF service, Simbrief, Navigraph enroute and airport charts, and made sure that every data block that I receive actually gets free’d. I indeed found a couple of occurences where the free() was missing. This, plus some other improvements seem to have fixed the issue.
If fsNetworkHttpRequestGetData() returns an XML or Json text, there’s the problem that this string is not zero-terminated. This lead to parsing errors, especially with the nlohmann Json library. My data[dataSize] = 0; solution however goes beyond the reserved buffer - I don’t know what I was thinking when I did this. My solution looks like this now:
Things look good again. I’m sorry to have bothered you guys with this, but until yesterday, it wasn’t clear to me that the crashes only occurred when the CRJ was linked to my Navigraph account. I thank you very much for looking into this