FSUIPC 7.4.18 unresponsive mid-flight

[aurel42]

Hey John, I've seen this issue multiple times, it usually happens like this:

I start MSFS and FSUIPC via MSFSAddonsLinker. I set up and start a flight in the LJ35. If I'm lucky, I can complete the flight. If unlucky, FSUIPC will become unresponsive at some point (ie. all FSUIPC-powered controls stop working, clicking or double-clicking the tray icon does not open a menu or the FSUIPC window). This seems to happen always right around the time when I try to change the selected altitude of the AP. In the LJ35, I'm using four LUA scripts to change the altitude, this is the "lj35_alt+1000.lua":

--Increment Alerter by 1000
  alerter_value= ipc.readLvar("L:ALERTER_DIGITAL")    -- get current value in altitude window
  alerter_value_new = alerter_value + 1000             -- add 1000ft to altitude from window 
  if alerter_value_new > 60000 then
   alerter_value_new = 60000
  end
  ipc.writeLvar("L:ALERTER_DIGITAL", alerter_value_new)  -- update window altitude
  altsel_mode = ipc.readLvar("L:MODE_ALTSEL")
  alerter_digital=ipc.readLvar("L:ALERTER_DIGITAL")                      -- get value in altitude window
  if altsel_mode == 1 then                                               -- check if necessary mode is on 
   ipc.control(66124, alerter_digital)                                 -- update sim, window altitude into AP_ALT_VAR_SET_ENGLISH
  end
  

I fly on FSEconomy using the FSE FSUIPC client. When FSUIPC becomes unresponsive, the FSE FSUIPC client aborts the flight, displays an error dialog telling me that the connection to FSUIPC has been lost, and then becomes unresponsive as well (ie. can't close the error dialog, can't interact with the main FSE FSUIPC client window).

I suspect it has to do with the LUA scripts, but I can't be sure. According to my logs, I've done dozens of successful flights in the LJ35 from January to May 2024, I haven't flown the Lear since. I never experienced any issues like this back then, only now when I started flying the Lear again recently.

Log attached (as usual I removed my license information). I'm not sure I'm willing to put much effort into testing and debugging this on my side, considering the imminent release of MSFS2024. IF the launch is smooth and the new version is reasonably stable and free of showstopping bugs, I'll probably spend my spare time exploring the campaign.

Nevertheless, if I can provide any additional information regarding this issue, please let me know.

 

FSUIPC7.log

[John Dowson]

If you restart FSUIPC, does it then work, or do you have to restart MSFS?

If you need to restart MSFS. you could be experiencing a WASM crash. To prevent this, you need to turn off ;var scanning in the WASM - see the following FAQ entry in how to do this:

If its not that, I will need further information.

What did you do when this occurred? Your log shows the lua script was killed, and 14 seconds later the WASM SimConnect connection was closed, but the log file wasn't closed:

Quote

   488844 Lvars/Hvars received - checking aircraft autos....
  1264516 LUA: "C:\Extras\FSUIPC7\lj35_alt+1000.lua": killed
  1405031   [INFO]: SimConnect_Close done
 

I am wondering what killed the lua script - maybe it hung (when trying to access lvars, as the WASM had crashed) and then you pressed a button to run it again, which would kill the running one?

[aurel42]

Thanks for your quick response, John! According to the FAQ entry, it wasn't a WASM crash, because there's an "END OF PROGRAM" line. There are ERROR messages in the WASM.log, but judging from the timestamps, they happened when I shut down MSFS. Find the log attached.

tbh, when it happened today, I ragequit. 😄

When I turned the rotary encoder to increase the selected altitude during climb and the numbers didn't change, followed immediately by the familiar bing sound, telling me that FSE had cancelled the flight, I just exited to the main menu and shut down MSFS. Since I had at least FSUIPC and the FSE client in an unresponsive state (both were still stuck after MSFS was gone), I restarted Windows to get rid of the processes, and I fired up X-Com to vent my frustration killing some aliens. 😄

If I experience the issue again, I can try to kill FSUIPC using the task manager and restart it to verify whether the WASM module is still working. I'll also make sure to test all my knobs, dials and axes to see if only the ones using scripts or presets are affected.

FSUIPC_WASM.log

[John Dowson]

1 hour ago, aurel42 said:

When I turned the rotary encoder to increase the selected altitude during climb

Yes, no WASM crash.

1 hour ago, aurel42 said:

When I turned the rotary encoder to increase the selected altitude during climb

Are your rotary encoder buttons assigned to run the lua script?
If a button is assigned to run a lua script, when the button is pressed, a thread is created, the script compiled and then ran. The problem with assigning rotaries to such scripts is that button presses are received faster that the previous button press is completed, so a subsequent button press will kill the lua thread from the previous button press, create a new thread and start again. And this is complicated by the lua thread having locks around the lvar access.
You can have lua assignments to buttons to perform single actions, but for repeated actions (which include button repeats and assignments to rotary buttons), you should use an auto-running lua that waits for the button press event with no assignment to the button in fsuipc.

To check this, can you activate logging for:
    - Events -(Log -> Events)
    - Buttons & Switches (Log -> Buttons & Switches)
    - Extras (Log -> Extras)
    - WAPI Debug (Log -> WAPI -> Debug)
and generate a new FSUIPC7.log file showing your issue, and attach that together with your FSUIPC7.ini file and the lj35_alt+1000.lua file.

John

[aurel42]

Gotcha, I'll reorganize the LUA scripts. So what's the theory what happens to FSUIPC when it becomes unresponsive? A race condition in the code that handles the lua threads, resulting in a deadlock?

It might be cliché, but ofc this worked flawlessly before. But it's been almost a year since, maybe I lost a couple of % of performance somewhere, maybe I've become more reckless twisting those knobs.

Thanks for your advice!

[John Dowson]

2 minutes ago, aurel42 said:

So what's the theory what happens to FSUIPC when it becomes unresponsive? A race condition in the code that handles the lua threads, resulting in a deadlock?

Something like that...I would need to see the logs to confirm (and may even need Trace logging enabled in the WAPI). In theory, the lua threads that are killed should release any locks, and the next lua thread should be able to obtain them. But sometimes lua threads don't seem to die completely and the locks are not released.
If FSUIPC is unresponsive, I would think this is due to some sort of race condition in the locking.

John

[John Dowson]

Actually, when a thread is killed/terminated, if it has any critical section locks, the state of those locks become undefined. So killing a lua thread that holds locks (i.e. if it accesses lvars) can cause issues.  I would have thought this would be timing dependent and quite rare though, so I am not confident that this is the actual issue...

John

[John Dowson]

,,,and another thing you could try is to increase the LuaRerunDelay ini parameter to a value that gives the lua script enough time to finish, so that subsequent button presses don't terminate the lua from the previous button press....