Jump to content
The simFlight Network Forums

LUA Error with ipc.runlua(path) Invalid Argument


Recommended Posts

You are correct. As I said above, in LINDA Setup, select Developer Mode and use dropdown to Verbose and tick LUA checkbox. This repeats the lower pane option in Console and stop you getting the warning message you are seeing. I have the test FSUIPC5 and will report back later. 

Link to comment
Share on other sites

  • Replies 66
  • Created
  • Last Reply

Top Posters In This Topic

42 minutes ago, Scotfleiger said:

This repeats the lower pane option in Console and stop you getting the warning message you are seeing.

Warning? You mean the one telling me the Logging is off? I thought that was useful. It's the part that tells me I can turn it on in LINDA Setup which is misleading, as it isn't in LINDA Setup but the dropdown from the Console -- except for Developers, or  do all users run in "Developer Mode"?

Pete

 

Link to comment
Share on other sites

Please stop. Obviously, my ability to communicate in English in failing. Please let me run the tests here when I get a moment. Please stop trying until I have time to think. I will get back to you when I have something more concrete. I should not be expecting you to learn a new utility remotely.

Link to comment
Share on other sites

Just now, Scotfleiger said:

Please stop. Obviously, my ability to communicate in English in failing. Please let me run the tests here when I get a moment. Please stop trying until I have time to think. I will get back to you when I have something more concrete. I should not be expecting you to learn a new utility remotely.

Sorry. I was only trying to help improve LINDA by pointing out misleading messages. I won't bother further.

Pete

 

Link to comment
Share on other sites

Hi Pete

Brain functioning again. Sorry!

I have run the 5.103a with the additional logging. In over 10 restarts I got one error report:

   238750 LUA.1: LINDA:: [START] Calling Initialisation...
   238750 LUA.1: LINDA:: [START] Path = linda/system/init
   238906 LUA: "C:\P3Dv4\Modules\linda/system/init.lua": killed
   240578 luaL_loadfile fopen error 0, filename ""
   240578 *** LUA Error: cannot open : Invalid argument
   253093 LUA: "C:\P3Dv4\Modules\linda.lua": killed
   253093 LUA.0: [START] *********************** STARTING LINDA ***********************

It appears that the file path passed is being lost between init.lua being killed and the runlua being executed. There is a 1672ms delay between these events.  After manually initiating a restart I have noticed a delay of 1600 to 2000ms.

 

FSUIPC5.log

Link to comment
Share on other sites

33 minutes ago, Scotfleiger said:

It appears that the file path passed is being lost between init.lua being killed and the runlua being executed.

I'll have to look along the wrole path of the execution from my code to that level, and add a log at every part. That isn't a quick job. if only I could reproduce it, it would be a lot easier (and quicker).

It must be something happening in the Lua code itself. The pathname certainly leaves my code intact, as you have shown. Also, seeing as it is so rare (for me, very; for you, somewhat), it must be some sort of timing interaction with other Lua parts. The separate threads really can't interfere (except via shared Globals) as they are effectively all in their own spaces with their own stacks.

I might not have time for this for a day or two, but I do want to see it solved, so do your work-around if you must but please allow it to be tracked still when I add more logging.

Pete

 

Link to comment
Share on other sites

On 6/28/2017 at 4:41 PM, Pete Dowson said:

I'll have to look along the wrole path of the execution from my code to that level, and add a log at every part. That isn't a quick job. if only I could reproduce it, it would be a lot easier (and quicker).

I've tried to do this in 5.103e (see the Download Links subforum), but I've only mamaged to check on a couple of levels above the failed "fopen" function. That it nested about 6 deep from your Lua (execurting the load in my C cde calls it directly, calling from within a Lua is complicated.

Getting into the code at layers above the lowest three or four is a nightmare. Data and parameters (especially) are on the Lua stack,  Working out where on the stack they are and what format everything is in is really difficult. the only was I can realistically track this down is by reroducing it here. Then I should be able to see that state at easch level.

By only guess at present is that something in your Lua code is corrupting something else, and whether it matters or not is less likely here than on the system you are using.

Get it to happen again with 5.103e and show me the log. i doubt it will tell me much, but you never know.

Pete

 

Link to comment
Share on other sites

Hi Pete

Thank you for getting back to me. I have implemented the workaround in code to detect the error and automatically trigger a restart. I am seeing the problem in the logs but not your level of debugging as before. Can you remind me of the Debug code you need me to use?

Link to comment
Share on other sites

Just now, Scotfleiger said:

I am seeing the problem in the logs but not your level of debugging as before. Can you remind me of the Debug code you need me to use?

There's no option. It wasn't worth making an option when it is very little extra code and just one extra log line when such an error occurs.

The now built in error message says:

   luaL_loadfile fopen error n, flags xxxx, filename "name"

The flags only mean something to me. I can track where they are set or cleared a the few levels I mnaged to add the empty "" filename check to.

That message will just precede the normal *** ERROR message you are getting.

Pete

 

 

Link to comment
Share on other sites

Hi Pete

I have run several test but the attached log includes your LuaL_loadfile message (a single occurrence). As suspected, the filename argument appears to be of zero length. I performed a number of forced restarts (using LINDA's CTRL_ALT+R hotkey) and also by changing the aircraft. On the last reset as init.lua is killed P3Dv4 crashed.

As mentioned, I now have a added a trap to detect the Invalid Argument and automatically trigger a LUA restart.

FSUIPC5.log

Link to comment
Share on other sites

13 minutes ago, Scotfleiger said:

As suspected, the filename argument appears to be of zero length.

The extra information I added was the "flags" part of the error message.  The fact that it is zero means that the filename part was of zero length for the four calling layers before the actual "fopen" which fails. I'm really not able, with spending many days on it, to track how this arrives at the earliest layer I was able to track to.

So the only way, I think, is for me to be able to reproduce it here. Unless you want a stab at debugging? You'd need Visual Studio 2015.

I might try tracking top down, rather than waiting for the error then tracking up to see were it gets lost. Remind me of the Lua code doing the looading. Is this this, from many messages ago?

path = ipc.get("PATH_SYS") .. "init"                    where PATH_SYS = linda/system/

    if file_exists(path .. '.lua') then
        ipc.runlua(path)
    else
        _log('[START] Unable to find INIT.LUA - Try Restarting')
    end


and you DID actually once test with "path" being logged before the runlua, didn't you?

Pete

 

 

Link to comment
Share on other sites

The code used in linda.lua (called from ipcReady.lua) is as shown.  It does a test to ensure path to init.lua exists before calling runlua(path). 

I don't possess Visual Studio and my knowledge of C is limited. I am happy with my workaround self-restart so don't waste your valuable time on this problem. 

Link to comment
Share on other sites

2 hours ago, Scotfleiger said:

The code used in linda.lua (called from ipcReady.lua) is as shown.  It does a test to ensure path to init.lua exists before calling runlua(path). 

I found that the fopen I was looking at was probably something related to other things your Lua stuff is doing. things like require" do file loads as well.

By simulating what you are doing I can see that they layering is not hard so I'm looking now (I will put a time limit on it) yto see if I can put traps elsewhere.

One thing you could do to help, please, is enable Lua trace in the Logging options. Obviously the log is going to get absolutely huge, so also selct the separate files option.  If you can get the error please try to make the relevant part of the relevant log small enough to post here or direct to me -- ZIP it of course. The trace from the INIT load beng honoured in that Lua and the resulting INIT log if there is any.

Pete

 

 

Link to comment
Share on other sites

25 minutes ago, Scotfleiger said:

ran the LUA logging enabled test for over 5 mins with multiple restart creating a 5GB file. There is one LuaL event at 178735. Zipped file attached.

The attached file is from a fresh load of P3D4 and if 5Mb long, not 5Gb! The entry at 178735 is 3 minutes into the run.

We should have used the Lua tracing berfore. I've been wasting my time. The error here:

   176641 LUA: "C:\P3Dv4\Modules\linda/system/init.lua": killed
   178735 LUA.1: C:\P3Dv4\Modules\linda.lua:157 fn: Start
   178735 LUA.0: beginning ""
   178735 luaL_loadfile fopen error 0, flags 0000, filename ""
   178735 *** LUA Error: cannot open : Invalid argument


Shows LUA.0: beginning "", which appears to be my own added code finding that the filename is already empty before the Lua code I've been trying to track is even called!

I'm in the process of scrapping all the extra logging I've been adding and will now look in my own code.

Pete

 

Link to comment
Share on other sites

33 minutes ago, Pete Dowson said:

I'm in the process of scrapping all the extra logging I've been adding and will now look in my own code.

Okay. there's not much for me to log n this part really. I've added a log line at the entry to the thread creation process, to make sure the fielname is still intact there, and then just before the loadfile is actually called. The acode in between looks pretty innocuous, but these two log lines will implicate or eliminate them and give me the next steop.

Download this special Test version (the new logging is temporary):

FSUIPC5103f_TEST.zip

You can take the trace option off. Please generate the error again and showw me that area of the log.

Pete

 

Link to comment
Share on other sites

I ran the test for 10 mins forcing the restarts.

On 15 occasions when I restarted I got:

   123859 LUA.1: LINDA:: [START] Calling Initialisation...
   123859 LUA.1: LINDA:: [START] Path = linda/system/init
   124016 LUA: "C:\P3Dv4\Modules\linda/system/init.lua": killed
   126109 LuaThread called: Entry 0, Filename "C:\P3Dv4\Modules\linda/system/init.lua"
   126109 About to load the Lua file: Entry 0, Filename "C:\P3Dv4\Modules\linda/system/init.lua"
   126141 LUA.0: LINDA:: [INIT] Starting Initialisation...

Only on one occasion I got:

   304641 LUA.1: LINDA:: [START] Calling Initialisation...
   304656 LUA.1: LINDA:: [START] Path = linda/system/init
   304797 LUA: "C:\P3Dv4\Modules\linda/system/init.lua": killed
   306906 LuaThread called: Entry 0, Filename ""
   306906 About to load the Lua file: Entry 0, Filename ""
   306906 *** LUA Error: cannot open : Invalid argument

   307563 LUA: "C:\P3Dv4\Modules\linda.lua": killed.                                                            <<<< automatic restart by LINDA   
   307563 LuaThread called: Entry 0, Filename "C:\P3Dv4\Modules\linda.lua"
   307563 About to load the Lua file: Entry 0, Filename "C:\P3Dv4\Modules\linda.lua"
   307563 LUA.0: [START] *********************** STARTING LINDA ***********************

Link to comment
Share on other sites

42 minutes ago, Scotfleiger said:

306906 LuaThread called: Entry 0, Filename ""

So the filename is disappearing immediately you execute the RunLua! Weird. I'll look to see where I can log closer to that, but there's not much involved.

Pete

 

Link to comment
Share on other sites

1 hour ago, Pete Dowson said:

I'll look to see where I can log closer to that, but there's not much involved.

Okay, almost the last gasp ...

FSUIPC5103f_TEST2.zip

This has the same version number etc, and two different log entries from before.

Please also enable Button/key logging in the FSUIPC logging options -- that gives me the "beginning" message too, without the Lua tracing needing to be enabled.

Pete

 

Link to comment
Share on other sites

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.