FSUIPC7 v7.2.10 Hang with lua crash error when ending flight and going to MSFS main menu

[John Dowson]

On 10/31/2021 at 12:15 PM, John Dowson said:

On 10/31/2021 at 12:01 PM, LeoSchoonbroodt said:

Another question, i put several ipc.sleep() calls in my script to not overrun the arduino's.
If there is an event during this time, will i miss this, or are the events hold in a buffer?

The events should be queued.

I don't think this is quite true...
I think some events will be queued but for others only the last event may be available. Best to experiment/test for this.
 

John

[LeoSchoonbroodt]

OK, If the last event is available that should be enough, will experiment.

 

Thanks again.

[LeoSchoonbroodt]

Hi John,

No lua-crash/FSUIPC7 hang anymore but recently 2 imes a FSUIPC7 CRASH.

Both direct afterloading the lua file and opening the comports.

Unfortunately i didn't save the FSUIPC7 log from the first one but i have the second one and both windows application event logs, so i send you these hoping you can pinpoint where it happens and the cause of it.

Its the version that you send as last, so with the code that prevents a hang when a lua file crashes.

EDIT: just happens Again, this time before loading the lua file, i attached 2 files FSUIPC7-CRASH-BEFORE-LOADING-LUA.log and its windows application log.

Cheers,

 

Leo

FSUIPC7_EXIT-after-Com-init.log FSUIPC7-CRASH.txt WINDOWS-APPL-LOG_FSUIPC7-EXIT-after-Com-init.log

FSUIPC7-CRASH-BEFORE-LOADING-LUA.log WINDOWS-APPL-LOG_FSUIPC7-EXIT-BEFORE-LUA-LOAD.log

[John Dowson]

I suspect that the crash before the luas were loaded may be to do with the WASM/WAPI but cannot confirm. Could you please add/change the following ini parameter to your FSUIPC7.ini file, under the [WAPI] section:
     LogLevel=Debug
and send me your log file(s) if/when you get a crash.
This is something I have experienced occasionally but cannot reproduce very often to track down.
Anyway, the logs should tell me if this is the issue or not.

For the crash after the luas were started, I have no idea...Has your lua changed again? Can you show it to me please.
I think you need to activate lua debug logging again if its crashing in the lua.

How often are you getting these crashes?

John

[LeoSchoonbroodt]

Ok, will change the ini file parameter and send you the logfile when it happens again.
 

Got no lua crashes anymore, and the FSUIPC7 crash happened 3 days ago and yesterday twice, so very randomly.
Have done at least 15 flights in that time.
If it happens more often, i will enable lua debug logging but my experience is that it slows my system that much that it becomes unusable, at least in a way that it misses button presses. I had sometimes to press a button 5 or 6 times before something happens.

Would maybe adding a ipc.sleep of a few seconds after opening the Com ports be a solution?
Because the crashes always happened immediately after that as far as i can see becuase my arduinos send some switchstates at initialization and there is one that is still not programmed in the lua, so i normally get the message RECEIVED: ZZ696690   NOT RECOGNISED/EXECUTED after initializing the Com ports and here i miss this message which indicates to me that connection is lost before this time.

 

Leo

[John Dowson]

2 minutes ago, LeoSchoonbroodt said:

Would maybe adding a ipc.sleep of a few seconds after opening the Com ports be a solution?

I don't think this would help but you could try it, won't do any harm.

John

[John Dowson]

Hi Leo,

just to let you know that I have released FSUIPC7 v7.2.12 with the above changes (and others).

However, I have made a small change in one of the areas. In the 2nd version I gave you to test, I added some extra code to kill luas earlier, with the SimStop message is received. However, I am not 100% sure on this change as spurious SimStop messages can be received during certain situations. Most of the time this doesn't matter (e.g. during start-up) but could possibly kill the luas when not needed (possibly on a flight reset). I have therefore made this 'earlier killing of luas' optional on an (currently undocumented) ini parameter, which is off by default. I suggest you keep this off initially, but if you get further issues with luas crashing (and maybe hanging FSUIPC) then you can re-enable this functionality by setting the following in the [General] section of your FSUIPC7.ini file:
    KillLuasOnSimStop=Yes

John

[LeoSchoonbroodt]

Thanks John,

Will keep you informed of how its going.

 

Leo

[LeoSchoonbroodt]

Hi John,

 

Using the new release v7.2.12 did not have to wait long on FSUIPC7 crash.

First flight, immediately showed my Cockpit didn't display values.
On check discovered that FSUIPC wasn't running anymore.
Sent you the FSUIPC7 log and the Windows Eventviewer Application log entry.

Directly after the crash i manually started FSUIPC7 and halfway the destination airport is still running.

Hope logs help to pinpoint the problem.

Just in case you need it, also included my lua script.

 

Leo

FSUIPC7_CRASH.log JS145.lua Windows-Application-Event-FSUIPC7_CRASH.txt

[John Dowson]

1 hour ago, LeoSchoonbroodt said:

Using the new release v7.2.12 did not have to wait long on FSUIPC7 crash.

Your log shows the crash was just after receiving the hvars for  the second time - the crash event was milliseconds after the last log message. This is the crash that I have occasionally experienced (and mentioned), but rarely, and have so far failed to reproduce to track. 
I am planning to investigate this one next week - taking the weekend off, bar minimal support, for a change! Hopefully get time to actually do some recreational flying as well...

If you get a crash, and it isn't directly after a 'EVENT_HVARS_RECEIVED' message (keep WAPI debug logging enabled), then possibly send me the logs. Otherwise  not necessary, but maybe keep a record of the crashes and circumstances.

You crash log this time shows lvar/hvar data being received both at 512 seconds after start, and again at 517 seconds, which is interesting... Did you perform a WASM reload to do this? I think the crash is somehow related to a WASM reload - may have missed some locks somewhere with data being read as its being overwritten, or a timing issue related to previous data, which is what I am planning to look into next week.

Note that, if reloading the WASM to catch lvars that aren't initially picked-up (a common problem, especially for more complex aircraft), then it is better to increase the WASM ini parameter LvarScanDelay. This is set to 5 (seconds) by default, but for complex aircraft I would recommend a setting of around 45, or to test by listing the lvars as the plane is loaded until you see you have them all (or nearly all...some seem to be created a lot later, but thats another story...), Check the WASM section in the FSUIPC Advanced User guide for details.

John

[LeoSchoonbroodt]

Hi John,

Hope you get the time and enjoy the recreational flying.
Everyone needs some time off for sure.

Is it possible that a WASM reload happens when i use Escape key to return to the menu and then resume, because i forgot to save my flightplan for display in Little Navmap?
Because that is something i do sometimes.

Another possible WASM reload is when i access a Lvar which returns nill, i do a WASM reload.
If that could cause it i will comment these out for test.

Will further investigate and as you asked, will report if i get a crash that isn't directly after a 'EVENT_HVARS_RECEIVED' message.
Will also adjust the WASM.ini parameter LvarScanDelay to 45 seconds.

Have nice flights.

Leo

[John Dowson]

13 hours ago, LeoSchoonbroodt said:

Another possible WASM reload is when i access a Lvar which returns nill, i do a WASM reload.
If that could cause it i will comment these out for test.

A nil is returned if the lvar wasn't loaded, so increasing the LvarScanDelay parameter should hopefully prevent this.
I would leave them in for now if changing that.

13 hours ago, LeoSchoonbroodt said:

Is it possible that a WASM reload happens when i use Escape key to return to the menu and then resume, because i forgot to save my flightplan for display in Little Navmap?

It shouldn't reload if you use the Escape key, only when an aircraft is initially loaded, or when a reload command is issued.

John

[John Dowson]

Hi Leo,

can you try the attached version please. The only change in this from the released version is updated multi-threading protection added aroung the reception of lvar/hvar names, but hopefully this should prevent the crash when receiving lvars/hvars. I haven't had time to fully test but it should be ok.... Of course, it won't help if your crashes are still related to lua coms.

John

FSUIPC7.exe

[LeoSchoonbroodt]

Hi John,

Will test this version this evening and report back.

Had yesterday evening again a lua crash after a plane crash. Went back to main menu after about a minute and about a minute after that exited MSFS.
No FSUIPC7 hang or message about terminating lua threads
Could it be this happens because of an abnormal end of flight?
Will investigate this further to see if i can make ir reprocucable.

Btw, was the first flight after enabling all WASM reloads for non-present Lvar's again.
Don't think this was the cause, because the refresh routines must have run several times before the crash.

Will send you the log anyway, because i cannot judge if it is of any value, if it's of no use for the problem you are investigating just disregard it.

Leo

FSUIPC7_LUA-CRASH_after_PLANE-CRASH.log

[John Dowson]

5 minutes ago, LeoSchoonbroodt said:

Had yesterday evening again a lua crash after a plane crash. Went back to main menu after about a minute and about a minute after that exited MSFS.
No FSUIPC7 hang or message about terminating lua threads

So there is no issue, no? Your log shows that FSUIPC exited normally due to MSFS exiting, which I presume you did... Your log is slightly strange though, as it looks like FSUIPC crashed as it was exiting  - the "FSUIPC Log file closed" log message was never reached...

12 minutes ago, LeoSchoonbroodt said:

Will send you the log anyway, because i cannot judge if it is of any value, if it's of no use for the problem you are investigating just disregard it.

But what problem do you think I am investigating? As I have said, I am not (and cannot) going to investigate the lua crash when exiting a flight if this isn't causing any issues, such as hanging FSUIPC.

Please only report back if you are having any actual issues - if the lua is crashing on exit, but not causing issues, I don't see any need to investigate. Of course, it would be nice to know the cause, but this is very difficult to investigate from here when i cannot reproduce.

If it does actually cause you issues, I could look into providing you with a debug-enabled version, and get you to configure and generate a crash dump file which I can use to debug, but I don't see a need to do this at the moment.

John

[LeoSchoonbroodt]

Hi John,

 

You mentioned investigating problems around WASM reload.

I do not know if that lua-crash has anything to do with this, as i got this crash on the first flight after enabling WASM reload on non-accessibility of a Lvar, i thought you would like to know this.
That's why i say if it is of no value, just disregard it.

I have no issues with it, as the lua would anyway be terminated at the end of the flight and doesn't hang FSUIPC7 , just didn't know if this special crash after crash situation would be of any value to know for you.

 

Leo

[John Dowson]

1 hour ago, LeoSchoonbroodt said:

You mentioned investigating problems around WASM reload.

Yes - the latest version I posted (above) should correct this problem.

2 hours ago, LeoSchoonbroodt said:

I do not know if that lua-crash has anything to do with this

No, nothing to do with the lua crash. That dix was for the other crash, when the last message logged (with WAPI debug level logging set) was for receiving the hvaar names.

2 hours ago, LeoSchoonbroodt said:

i got this crash on the first flight after enabling WASM reload on non-accessibility of a Lvar, i thought you would like to know this.

Maybe, but your log shows it had nothing to do with the WASM, and in fact FSUIPC closed down due to MSFS exiting - you did get a lua crash but it didn't stop FSUIPC from running. Maybe it caused some issues as FSUIPC failed to close down completely correctly, but as it was closing anyway I think this should be ok.

2 hours ago, LeoSchoonbroodt said:

I have no issues with it, as the lua would anyway be terminated at the end of the flight and doesn't hang FSUIPC7 , just didn't know if this special crash after crash situation would be of any value to know for you.

I am only interested in seeing your logs if a lua crash (or anything else) is causing you issues. If its crashing occasionally at the end of a flight, but causing no issues, there is no point posting me the log.

In summary, only show me your files if you are having a problem, not just because of a lua crash that caused no issues.

John

[LeoSchoonbroodt]

Well John,

Using your version 7.2.13

Looks like the FSUIPC7 Hang isn't solved by your code. You didn't remove it, didn't you?

First flight  and ending of MSFS did FSUIPC7 not end with when MSFS exited, had to end it in TaskManager.

Second series of flights, at last flight when entering Main Menu I got again an FSUIPC7 hang and had to exit it again with TaskManager
Send you the Logs and TaskManager screens.

Leo

FSUIPC7_does-not-end.log FSUIPC7_HANG-ENTERING _MAIN-MENU.log TESTSEQUENCE.txt

[John Dowson]

14 hours ago, LeoSchoonbroodt said:

Looks like the FSUIPC7 Hang isn't solved by your code. You didn't remove it, didn't you?

No, the only changes in that last version were relates to the WAPI (lvar/hvar access interface).

Both of the hangs are due to the same reason, which I suspect is due to multiple threads holding/waiting for locks (i.e. one thread has a lock on X, waiting for a lock on Y, while the other has a lock on Y, waiting for a lock on X) during shutdown, or the WAPI thread os trying to exit while a lock is held but hasn't been released. I will revise the locking code I recently added (and add more logging to try and track this down).

Are you using the additional ini parameter I added:
     KillLuasOnSimStop=Yes
?

John

[John Dowson]

Found a cut-and-paste error in the locking, which resulted in a lock being obtained but not released. This is corrected in the attached version.

Sorry about that.

John

 

FSUIPC7.exe

[LeoSchoonbroodt]

Ok, glad you found that.

Will test the new version this evening, are working now.

Will check also on that ini parameter, can't remember at the moment, changed that much lately.

Thanks,

Leo

[John Dowson]

54 minutes ago, LeoSchoonbroodt said:

Will check also on that ini parameter, can't remember at the moment, changed that much lately.

Ok. Best to try without this first, and only add if you get issues.

John

[John Dowson]

Hi Leo,

Not heard much from you recently - is this a good sign?

John

[LeoSchoonbroodt]

Hi John,

Yes everything works as expected no FSUIPC7 hang, no LUA crash, even without the KillLuasOnSimStop=Yes parameter, but have to say that i, because of some work i had to finish, didn't have more than a few flights a day last days.

So i decided to wait a few more days before reporting back, also because i know you must have more work to do and didn't want to report "everything OK" before i really am shure it is.

As long as you don't hear anything you can asume that i didn't encounter anything disturbing.

Will keep you informed when things change.

Leo

[LeoSchoonbroodt]

Hi John,

Sadly, Not OK anymore after todays first flight, entering the main menu, FSUIPC7 exited while MSFS still running.

Didn't notice until i after having dinner started a new flight and discovered that my lua wasn't executed (cockpit did not initialise).
Send you the FSUIPC7.log and the Windows Application event log text.
Last entry in logs states that FSUIPC7 is waiting for the the lua to process the termination event.
All this does is closing the Com Ports, sleep for 500 ms and then execute an ipc.exit()
But included the lua file anyway in case you want to verify what's happening during this event.

Must have about 7 or 8 flights that worked fine last days.

EDIT: Next flight, same result, send those logs too.

Will restart MSFS to see if that solves it.
Very strange, so many good flights and then 2 fail after each other.
Restarted MSFS and had a flight without problems, don't know if this has something to do with it.

EDIT 2:

Just realise, today is the first day i used AirForcePlayer, a program to simulate Force Feedback on my MS Sidewinder 2 FFB Joystick.
It's a program that uses the MS DirectInputAPI, don't know if it's something but will test tomorrow without it and the day after with it to see if it's making a difference.

Leo

FSUIPC7_exited on return to main menu.log Windows Application log FSUIPC7 exit.txt JS145.lua

FSUIPC7_exited on return to main menu-2.log Windows Application log FSUIPC7 exit-2.txt