Jump to content
The simFlight Network Forums

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


Recommended Posts

Posted

Hi John,

I have the registered version of FSUIPC7 v7.2.10 and Wideclient v7.160

When i end a flight and want to start another one, the lua file for the plane is not loaded and when investigating the matter it seems that FSUIPC isn't responding anymore.

I have to end FSUIPC via taskmanager and start it again.

In the log i find a lua crash error 7871063 LUA.1: Crash E06D7363 at 7FFB5FC24F99: "F:\FSUIPC7\JS145.lua" 

I do not get any errors in the lua editor and everything runs fine during flight.

I included the FSUIPC logfiles.

This happens a few weeks now, don't know exact time, because i first thought it was an incident and did not pay to much attention to it.

Thanks for any advise to solve this.

 

With kind regards, Leo Schoonbroodt

 

FSUIPC7 Hang ending flight.log FSUIPC7_HANG AT AIRPLANE CHANGE FROM H145 TO R44.log FSUIPC7_hang.log

  • Replies 53
  • Created
  • Last Reply

Top Posters In This Topic

Posted

Hi John,

 

Attached the lua file.

It works fine mostly but sometimes when ending a flight I get this error.

don't worry, no hurry, downloaded 7.2.11 today and until now still not happened.

Also i don't know for sure if a plane change is needed for it to happen so in a few days i probably have more information about the conditions when it happens.

will test further with 7.2.11

Thanks for your time investigating it.

JS145.lua

Posted

There seem to be two issues here:
 1. the lua thread crashing
 2. the crashed thread hanging FSUIPC

I will look into item 2, however it would be good to know why the lua thread is crashing and try to prevent this.
Could you activate lua debug logging, and produce a log file where you get the lua crash. It could be quite large, so you may need to zip it up.

It is most probably an issue with the com library that is causing the issue. You could register and use an event.terminate function to explicitly close the com connection, which may help. See the lua library document for details.

I notice that your script is also using the ipc.display function. Are you having any success with this? The simconnect API function that this relies on (SimConnect_Text)  has been partially broken since the initial release of MSFS, and it was completely broken in the SU5 update and is still documented as 'not currently available for use' in the latest SU6 update. Due to this, we recommend switching to using the lua wnd library instead.
However, I don't think this jas anything to do with the crash you are experiencing.

John

 

Posted

Hi John,

Will run this evening with Lua debugging.
Display function is indeed not working anymore is still present (as a few other things) from a previous version when it was working.

Wil allso use the event.terminate function and remove some other old stuf which isn't used anymore just to make the file more readable.

After that will send you new information.

 

Thanks so far for investigating things.

Posted
5 hours ago, LeoSchoonbroodt said:

Will run this evening with Lua debugging.
Display function is indeed not working anymore is still present (as a few other things) from a previous version when it was working.

Wil allso use the event.terminate function and remove some other old stuf which isn't used anymore just to make the file more readable.

After that will send you new information.

Ok, thanks. Let me know how it goes and send me the logs when you have issues. Thanks,

John

Posted

i John

Implemented the event.terminate and in this routine i close the com ports. Also implemented a check if a comport is open before sending data.


Took a while because if i set lua-logging, my system becomes very slow, so slow that the lua script missed several events and could not get a hang of FSUIPC, unless i turned lua logging off.

So i modified my JS145.lua to send less info to the arduino's (i think the sim updates some events at the fps rate and my script couldn't keep up with this)

So i replaced some event driven data transfers to 250 ms (UpdateTimer) driven data and also cleaned up a little bit unused things, more for readabillity because the airplane is a work in progress and so is the lua file for it.

Tested today and did a flight this afternoon with logging off and switched logging on just before return to the MSFS main menu, the point where it always happened

I got a FSUIPC hang and include the log and the lua file (because it has changed).

Hope this helps to pinpoint the problem.

 

Leo

FSUIPC7.log JS145.lua

Posted

Could you also show me your FSUIPC7.ini file please.
Also, next time you post a log, could you please post the complete log file and not start a new one. It may be quite large, but should zip up ok.

Could you also confirm that this only happens when going back into the MSFS main mene (i.e. when ending a flight).
And does it now always occur when you end a flight? From an earlier log you posted:

Quote

  8179922 Sim stopped: average frame rate for last 7916 secs = 13.7 fps
  8179922    Max AI traffic was 48 aircraft
  8179922 -------------------------------------------------------------------
  8185890 Lua threads being terminated:
  8185890       1 = "F:\FSUIPC7\JS145.lua"
  8186109 LUA: "F:\FSUIPC7\JS145.lua": killed
 11176015 Sim stopped: average frame rate for last 2990 secs = 19.7 fps
 11176015    Max AI traffic was 1 aircraft
 11176015 -------------------------------------------------------------------
 11179328 Planned flight from EDDL to EDDL
 11179328 \\FSX\MSFSdata\LOCALSTATE\MISSIONS\CUSTOM\CUSTOMFLIGHT\CUSTOMFLIGHT.PLN
 11189937 Lvars/Hvars received - checking aircraft autos....
 11465812 Sim stopped: average frame rate for last 283 secs = 27.5 fps
 11465812    Max AI traffic was 35 aircraft
 11465812 -------------------------------------------------------------------
 11470047 LUA.2: Crash E06D7363 at 7FFB5FC24F99: "F:\FSUIPC7\JS145.lua"

This shows that the first time you stopped a flight, the lua file was killed/terminated ok, but the 2nd time it has the lua crash.

I will see if I can add some further logging to track down the issue, and why there is such a delay (>5s) between the 'Sim stopped' and the lua threads being terminated.

John

 
Posted

No it doesn't happen always, and it indeed happens only when i go back to the main menu.

I tried to kill the lua manually by reloading it, in the past but as far as i can remember this never was a problem.

The reason i started a new one was indeed to only log the part where it happens, that's also the reason why i started logging when finishing the flight.

If i start the logging earlier, it slows my system in such a way that the script misses a lot of button events. In fact it is unflyable.

But i could start logging, load a flight and then whitout taking off go back to the main menu. Have to exercise this until i get a crash/hang.

I included the FSUIPC.ini and the JS145.ini.

Wil start above procedure and see if i get a crash/hang in which case i send you the complete log.

 

Leo

FSUIPC7.ini JS145.ini

Posted
14 minutes ago, LeoSchoonbroodt said:

Wil start above procedure and see if i get a crash/hang in which case i send you the complete log.

Yes - it doesn't matter when you start the logging, but the complete log is needed,
Also, can you show me your GetComPorts.lua script, as this is ran from within your JS145.ini script.
Any reason why this is in a separate script rather than a function? Does that script keep running once it has set the ComPortsLoaded variable? If not, maybe try to remove that call and load the com ports from within the JS145.lua script itself (which now has a .ini extension in the last one poted....?!!!). This would at least tell us if its a dangling thread from that call that is preventing the JS145 thread from terminating.

John

 

 

Posted

Btw, how are you starting this lua?
There is no [Auto] section (or [Auto.xxx] sections), and no ipcInit.lua or ipcReady.lua.

In fact, you have various profiles set-up, but nothing that uses them (i.e. no profile sections for axes, buttons, keys, calibration, autos,...).

 

Posted

John,

The JS145.ini is the profile file not the lua file, the lua file was posted in a previous post.

The reason this GetComPorts.lua is executed is when the arduino's are plugged to another port which changed the comport of it.

The Getcomports.lua is not dormant and was used in a separate file because its only used when i switch hardware which is maybe once in a month or less.

I will post it, but i also just comment the call for testing so it will never be called, just to be shure it is not the cause.

Post the modified JS145.lua and Profile file JS145.ini too.

 

Leo

GetComPorts.lua JS145.ini JS145.lua

Posted
15 hours ago, LeoSchoonbroodt said:

The JS145.ini is the profile file not the lua file, the lua file was posted in a previous post.

Ok, now I understand. However, what threw me i that in your FSUIPC7.ini you have:
     UseProfiles=Yes
and not
     UseProfiles=Files

So your main FSUIPC7.ini is not configured to use profiles as separate files.  So I am confused to how your JS145.ini is being used, and thus how the JS145.lua is being started.

John
 

Posted (edited)

Could you try the following version please, which has some additional logging added. The lua will still crash, hopefully/maybe FSUIPC will continue (but probably not!) but some ectra logging should be avaiable - please show me your full FSUIPC7.log.
You inly need to show me your lua & ini scripts again if they change. Thanks,

John

PS. You can turn off lua debug logging for the time being - I will advise if/when it needs to be activated again

Edited by John Dowson
PS added
Posted

John,

Did yesterday evening a lot of testing but could not get a lua crash.

only thing changed is that i outcommented the GetComPorts.lua

But this script was last run on september 16 as i can see at the creation date of the created ComPorts.txt file.

Will further test with the provided versions and when i get a lua crash and/or FSUIPC hang i will post the complete log.

Leo

Posted
42 minutes ago, LeoSchoonbroodt said:

only thing changed is that i outcommented the GetComPorts.lua

Ok, that is interesting.... sounds like that thread is somehow preventing the main thread from closing...

45 minutes ago, LeoSchoonbroodt said:

But this script was last run on september 16 as i can see at the creation date of the created ComPorts.txt file.

...hmm, then maybe not!

You could also try renaming that file and uncommenting the ipc.runLua command so that it is re-created, and see if that provokes the crash, or not, as the case may be.

Anyway, I will wait for further information. I am not sure if the changes in those above versions will be kept for the next release or not, we'll see how it goes with your tests.

John

Posted

Hi John,

Testing yesterday with the first posted version, could not get a crash/hang.

Changed a lot of things to try to get a lua crash with no result.

At the end i also changed the outcommented display statements to log statemens because it displays info about the execution,
all without changing linenumbers of the rest of the JS145.lua.

To many things to mention, so i included a TESTSEQUENCE.txt which describes the things i tried and the result and name of the logfile involved.

I am testing now with the second version but until now without crash/hang.

Will keep you informed about the results.

Leo

ComPorts.txt FSUIPC7_Disconnected ComPort-7.log FSUIPC7_OK_EMPTY_COMPORTS_RECREATED.log FSUIPC7_OK_with_new_ComPorts-txt_and_Aircraft-change.log FSUIPC7_OK-NEW ComPorts-txt-made.log FSUIPC7_OK-with reconnected Com7-after-previous-CTD.log FSUIPC7-reconnected Com7-then-CTD.log JS145.lua TESTSEQUENCE.txt

Posted

Hi John,

Did yesterday a flight with the second of the above downloaded versions of FSUIPC7 during which i several times manual reloaded the JS145.lua because i got a build from the developer of the H145 Airbus helicopter that has some Hvars fixed that i reported earlier as not working.

During this reloads for testing there was never a problem but when finished and returning to the main menu i got a lua-crash but this time without hanging FSUIPC7, so i think your code to prevent this hang is working,

I did some flights to test the new Hvar functionality to report back to the developer, all without a problem.
Today i get family visit over here so don't have the time to try and replicate te situation and test again and again.

Don't think the lua file was the cause because several flights after the crash went well, but to be complete still included the active one in the post, especially because it is changed after the last one i posted.
The Plane is a Work In Progress, so is the JS145.lua

See if i can find time somewhere to try and replicate the crash.
If you have any suggestions what to test to pinpoint this, please let me know.

Leo

FSUIPC7_lua-crash_NO-hang.log FSUIPC7_OK-1.log FSUIPC7_OK-2.log JS145.lua TESTSEQUENCE.txt

Posted
19 minutes ago, LeoSchoonbroodt said:

See if i can find time somewhere to try and replicate the crash.
If you have any suggestions what to test to pinpoint this, please let me know.

As the crash is when the lua thread is being terminated, and this does not cause FSUIPC to hang, I really don't think its worth investigating this any further.
But one thing is slightly strange - you say "at the end when going to main menu: lua crash but NO HANG", but the log file shows:

Quote

...
  4748109 -------------------------------------------------------------------
  4752047 LUA.4: Crash E06D7363 at 7FFE7F484F99: "F:\FSUIPC7\JS145.lua"
  4763094  [ERROR]: Error clearing config data definition
  4763203   [INFO]: SimConnect_Close done
  4769078 MSFS no longer running - exiting
...

i.e. FSUIPC7 exited about 1.5 seconds after the crash as MSFS was no longer available. Did you exit MSFS once in the main menu?

John

Posted

John,

I always check the log after exiting to the main menu and if find a lua crash check if FSUIPC7 IS STILL RESPONDING.

As i found above result i exited MSFS but i think it was after about 10 seconds.
If the times in the log show miliseconds as i think, then that's about what the log shows also?
4763094 -  4752047 is about 11 seconds then?

Will keep you informed if i get any new hangs because as you stated, that lua crash really doesn't matter because it was terminating anyway.

Still would be nice to know what caused it initially to see if it maybe could give some problems at other places but agree there are probably more urgent things to resolve as the impact of te crash is now solved.

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?

 

Leo

 

Posted
4 minutes ago, LeoSchoonbroodt said:

If the times in the log show miliseconds as i think, then that's about what the log shows also?
4763094 -  4752047 is about 11 seconds then?

Yes, sorry - missed a d.p.!

6 minutes ago, LeoSchoonbroodt said:

Still would be nice to know what caused it initially to see if it maybe could give some problems at other places but agree there are probably more urgent things to resolve as the impact of te crash is now solved.

The crash will be related to the closing down of the lua threads when using the COM interface, and is most probably a timing issue somewhere, and I doubt very much its an issue that can cause problems elsewhere.

11 minutes ago, 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.

Cheers,

John

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.