Corrupted LVars names using ProSim B738

[DaddyBoon]

Hello,

Since a few days we are getting a couple of "strange" (corrupted) LVars names. When it occurs, MSFS Disconnect / MSFS Reconnect from FSUIPC menu often solves the issue.

MSFS show correct names ("B738_Beacon_Light_Dn", "B738_Logo_Left") but WASM don't: some names are truncated and end with one or two non printable characters ("rectangles").

This now occur with old FSUIPC version (restored from a backup) and with various ProSim versions (beta 3.32bxx and 3.31 release).

What could be the reason?

Attached file contains FSUIPC7.log and FSUIPC.ini 🙂

Best regards,

Didier

Posted on forum.homesim.aero too (https://forum.homesim.aero/viewtopic.php?t=28299)

 

 

Edited November 13 by DaddyBoon
Added LOG and INI

[John Dowson]

2 hours ago, DaddyBoon said:

Since a few days we are getting a couple of "strange" (corrupted) LVars names.

That is very strange! Did anything change to cause this? It does look like a memory corruption issue, which is very strange, and also seems to occur when FSUIPC is started,

2 hours ago, DaddyBoon said:

When it occurs, MSFS Disconnect / MSFS Reconnect from FSUIPC menu often solves the issue.

Ok, then that would seem to indicate that this is on the client side (WAPI) rather than in the WASM,

2 hours ago, DaddyBoon said:

What could be the reason?

Not sure at the moment. Could you set Debug level logging in the WAPI (Log->WAPI->Debug) and show me/attach another log file. As it seems to happen straight away, you could even set Trace level logging in the WAPI. Can you also set Debug level logging in the WASM (via the FSUIPC_WASM.ini - see Advanced User manual for details on where this is) and also include/attach your FSUIPC_WASM.log file.

John

[DaddyBoon]

Hello 🙂

Here are the log files I got this morning (size exceeds 20 kB).
I hope they can help.

Best regards,

Didier
 

Edited November 13 by DaddyBoon

[John Dowson]

Your log files are very interesting...
They show the lvar names correctly in the initial scan, when 134 lvars are detected, but (97 seconds) later 137 lvars are detected and two of the lvar names have been corrupted.
This corruption looks to be in the WASM, so I am surprised when you say that 'MSFS Disconnect / MSFS Reconnect from FSUIPC menu often solves the issue'. However, to confirm this, I would need to see an FSUIPC_WASM.log with Trace logging activated.

It is strange that the following 3 lvars are created such a long time after aircraft load:

    77391  [TRACE]: LVAR Data: name='FSDT_VAR_Frozen'
    77391  [TRACE]: LVAR Data: name='B738_EmergencyDoors'
    77391  [TRACE]: LVAR Data: name='Prosim738_Steering'
 

There is a known issue with scanning for lvars that can cause the FSUIPC WASM module to crash. See 

It looks like you are getting a similar issue, but rather than a WASM crash you are getting a memory corruption somewhere.
To prevent this, try tuning your WASM ini parameters. You currently have these set:

Quote

Wed Oct 30 08:17:25 2024  [ALWAYS]: lvarScanDelay = 5
Wed Oct 30 08:17:25 2024  [ALWAYS]: lvarScanFrequency = -5
Wed Oct 30 08:17:25 2024  [ALWAYS]: lvarScanPeriod = 120

Try with:

LvarScanFrequency=-30
LvarScanDelay=10
LvarScanPeriod=-4

If you still get issues, and if not using those 3 additional lvars (mentioned above) directly (you can still use them via presets/calculator code), you could disable continual lvar scanning by setting:
    LvarScanFrequency=0

There seems to be something un MSFS that is corrupting the lvar name space, which I reported to MSFS a while ago but have yet to receive a response. I have ran the FSUIPC WASM in a debugger for days at a time and have not seen any corruption in the WASM itself, so this seems to be an MSFS issue...

John

[DaddyBoon]

Hello John,

This need to be confirmed... I think you gave me the right clue to solve our issue.
In FSUIPC_WASM.ini, I've changed the values of LvarScanFrequency and LvarScanDelay:

;LvarScanFrequency=-5
LvarScanFrequency=0

And

;LvarScanDelay=5
LvarScanDelay=35

Perhaps editing solely LvarScanDelay could be enough? Later, I'll try to restore LvarScanFrequency  value...

Here are the new log files I gathered this morning:

• Subfolder "FAILS" with trace, you'll notice those LVar's names (line 252874 in FSUIPC_WASM.log)

  Thu Oct 31 09:15:00 2024   [TRACE]: updateLvars: lvar updated: B738_Landing_L=0.000000
  Thu Oct 31 09:15:00 2024   [TRACE]: updateLvars: lvar updated: t 31 09:15:00 2024=0.000000

   

• Subfolder "WORKS" with trace, using my new FSUIPC_WASM.ini

Thank you for your help, best regards,

Didier

Edited November 13 by DaddyBoon

[John Dowson]

53 minutes ago, DaddyBoon said:

Perhaps editing solely LvarScanDelay could be enough?

No - that ini parameter just specifies the just delay between aircraft load and the first scan for lvars. It seems to be repeated scanning for lvars that is causing this issue, and that will still occur.

57 minutes ago, DaddyBoon said:

Subfolder "FAILS" with trace, you'll notice those LVar's names (line 252874 in FSUIPC_WASM.log)

Thu Oct 31 09:15:00 2024   [TRACE]: updateLvars: lvar updated: B738_Landing_L=0.000000
Thu Oct 31 09:15:00 2024   [TRACE]: updateLvars: lvar updated: t 31 09:15:00 2024=0.000000

That is very interesting...that does indicate to me that there maybe is a memory issue  somewhere un the WASM - I will look into this (again)....

Thanks for your files/input on this. I will update if/when I find amything.

Regards,

John

[DaddyBoon]

Hello John 🙂

The issue seems to have vanished since I've added an entry in ipcReady.lua 🤔

I added "ProSim-Lvars.lua" to instantiate some LVars useful to the new vmsACARS version.
Previously I had a "sort" of empty ipcReady.lua (old LUA got commented as new ProSim versions did not need them anymore):
 

-- ipc.macro("Lua:ProSim-60knots")
-- ipc.macro("Lua:ProSim-positive-rate")
-- ipc.macro("Lua:ProSim-Lights")
-- ipc.log("Ready: GearUpGearDown")
-- ipc.macro("Lua:GearUpGearDown")
-- ipc.runlua("ProSim-Rain")

Could having an "empty" ipcReady have caused the issue I observed??? Or could creating LVars (my new LUA) have add some nice effect??

Kind regards,

Didier

ProSim-Lvars.lua

[John Dowson]

On 11/18/2024 at 11:35 AM, DaddyBoon said:

Could having an "empty" ipcReady have caused the issue I observed???

No - the script would just run and finish.

On 11/18/2024 at 11:35 AM, DaddyBoon said:

Or could creating LVars (my new LUA) have add some nice effect??

I can't see how this can do much with the WASM CTD issue...

The script is not very efficient as it is poling and thus writing/updating lvars and offsets 4 times a second, regardless of whether the values have changed or not. Would be better to use events on both the offsets and the lvars, and only update the lvars when the offset value changes,  and update the offset when the lvar value changes.

John