Context:What package? When editing or mounted from Community? In main menu or in flight? etc…
In Flight
Bug description:
I have a WASM module that scans for available lvars using the following code fragment:
// Check if more lvars available
int noLvarsAvailable = 0, msgLength;
bool isValidLVAR = true;
PCSTRINGZ lvarname;
do {
lvarname = get_name_of_named_variable(noLvarsAvailable);
if (lvarname)
{
msgLength = snprintf(szLogBuffer, 512, " Lvar found: id %d = '%s'", noLvarsAvailable, lvarname);
if (msgLength > 0 && msgLength < 512)
LOG_TRACE(szLogBuffer);
else
{
snprintf(szLogBuffer, 512, "*** Lvar id %d (%d chars): '%s'", noLvarsAvailable, strlen(lvarname), lvarname);
LOG_ERROR(szLogBuffer);
}
noLvarsAvailable++;
}
else
isValidLVAR = false;
} while (isValidLVAR);
This generally works just fine. However, it seems that in certain circumstances (which I personally am unable to reproduce) this code can crash the WASM in the call to get_name_of_named_variable
Repro steps:
I cannot reproduce this, but have determined that the WASM is crashing here due to others who are using my WASM. It seems that this crash only occurs when using complex aircraft AND complex scenery. I have tried to reproduce when running my WASM in an attached debugger many times without success, but the WASM crash does occur quite frequently for some of the users of my WASM module.
Is it possible that some scenery or add-on is corrupting the lvar name space that is causing this issue?
Attachments:
Private attachments: Send a PM to @PrivateContent with the link to this topic and the link to download your content
I am not sure I should have raised this as a bug, as I cannot reproduce and it seems to occur when using multiple add-ons. Shall I delete this bug report and re-submit as a question?
It is a serious issue though for many of my users and any information on how to track this down further would be much appreciated. For example, as I cannot reproduce this myself, is there any way I can get a crash dump of the WASM from users who experience this issue so that I can submit this to Asobo for analysis?
If not, are you sure it’s not crashing in the logging parts? Or did you add that to try debug the issue?
I’ve crashed a module before by trying to log non-printable characters to stdout (the dev mode console), for example. It’s not hard.
My module routinely does this (essentially) and I’ve not heard of any crashes (FWIW)…
int i = 0;
while (true) {
PCSTRINGZ varName = get_name_of_named_variable(i++);
if (!varName)
break;
//...
}
Just curious, why bother with buffers and printf? Why not just std:::cout << ... << std::endl;
?
I adapted this simple but nice logging lib for use in my module. It has logging levels and can write to file as well as stdout/err. Perhaps you’ll like it. The main, and minor, adjustment is to disable the std::threading usage, from <thread> and <mutex> includes.
No…but I have further information. Seems to be a memory corruption issue somewhere, but not sure where as it now seems to corrupt the lvar names and not crash the WASM. For example, see this log extract:
Thu Oct 31 09:15:00 2024 [TRACE]: LVAR found: 50=XMLVAR_Baro1_Mode
Thu Oct 31 09:15:00 2024 [TRACE]: LVAR found: 51=B738_Landing_Light_Left
Thu Oct 31 09:15:00 2024 [TRACE]: LVAR found: 52=B738_Landing_Light_Right
Thu Oct 31 09:15:00 2024 [TRACE]: LVAR found: 53=B738_Taxi_Light
…
Thu Oct 31 09:15:00 2024 [TRACE]: updateLvars: lvar updated: XMLVAR_Baro1_Mode=1.000000
Thu Oct 31 09:15:00 2024 [TRACE]: updateLvars: lvar updated: B738_Landing_Le=0.000000
Thu Oct 31 09:15:00 2024 [TRACE]: updateLvars: lvar updated: t 31 09:15:00 2024=0.000000
Thu Oct 31 09:15:00 2024 [TRACE]: updateLvars: lvar updated: B738_Taxi_Light=0.000000
…
And it does look like it might be related to logging, as it seems to be a timestamp that is corrupting the lvar namespace,
That was added to debug the issue - the crash occurred without this.
Because I do not log to cout. I also use a logging framework (notice LOG_DEBUG, LOG_TRACE, etc).
Looks similar to the one I adapted and use…
Could this be due to multi-threading and no lock control around my logging? I thought all WASMs currently run in a single thread (the main thread).
There is locking via mutex in my logging framework although this is currently also disabled (as not avaiable in a WASM, or so I thought…).
Anyway, thanks for your input. As I say, I cannot actually reproduce this myself, and only seems to occur with certain aircraft (e.g. Prosim 737) which I do not have. I have ran my WASM for days at a time, using many different aircraft, both default and add-on, and while connected to the VS debugger, and have failed to catch any memory issues.
I will probably close this ticket shortly as I no longer think it is related to the get_name_if_named_variable call, but I just don’t know what more I can do to track this down at the moment.
Yikes! Indeed, looks like some funky value, or something just “crashed” in that model. That’s kinda what I was wondering about with the logging question, though that was misdirected since you’re not writing to stdout (my confusion, sorry).
I’m guessing it’s not a timestamp but the value of one of those vars can’t be printed correctly and it’s just messing up the log output itself. The var’s output was already corrupt before logging got involved. Whether that can crash the logger/module or not, of course I can’t say.
And I doubt it’s a concurrency issue… indeed there’s no way I know of for any concurrency to occur in the WASM modules (never mind actual multi-thread access). I imagine it could screw up a lot of current module designs if there was any (including mine certainly, since there are no mutexes or atomics or anything to lock global/shared data with).
One sure way I know of to try to log some bogus stuff is to run some RPN through gauge_calculator_code_precompile() and then try to print the resulting bytecode (as a plain string). At least if printing to stdout/console, things go boom (not sure I tried with just file logging). Not a useful way to debug that output…
As for that logger I use… I like it 'cuz I can just stream to it, eg LOG_DEBUG << "foo" << foo; and that it is “lazy” meaning if for example you’re logging an expression at TRACE level but trace level is disabled, the expression never even gets evaluated.
Anyway, certainly seem like something going on with that particular model, though it wold be interesting to know what exactly causes it (on both their model and your module side). Wonder what else that could crash in the sim.
