LUA Error with ipc.runlua(path) Invalid Argument

[Scotfleiger]

got it

[Scotfleiger]

Ran the latest test twice. On both occasions, P3Dv4 eventually crashed at the point RunLua(path) was called on restart.

In log-A, it came up with Filename "" on first running the initialisation code but went on to create the new thread, the same occurred in Log-B:

    92937 LUA.1: LINDA:: [START] Calling Initialisation...
    92937 LUA.1: LINDA:: [START] Path = linda/system/init
    92953 RunLua just called: Filename ""
    92953 About to Create the Lua thread: Entry 0, Filename "C:\P3Dv4\Modules\linda/system/init.lua"
    92953 Create Lua thread: Entry 0, Filename "C:\P3Dv4\Modules\linda/system/init.lua"
    92968 LUA.0: LINDA:: [INIT] Starting Initialisation...

Others, killed init.lua:

   151078 LUA.1: LINDA:: [START] Calling Initialisation...
   151078 LUA.1: LINDA:: [START] Path = linda/system/init
   151078 RunLua just called: Filename "C:\P3Dv4\Modules\linda/system/init.lua"
   151234 LUA: "C:\P3Dv4\Modules\linda/system/init.lua": killed
   153328 About to Create the Lua thread: Entry 0, Filename "C:\P3Dv4\Modules\linda/system/init.lua"
   153328 Create Lua thread: Entry 0, Filename "C:\P3Dv4\Modules\linda/system/init.lua"
   153343 LUA.0: LINDA:: [INIT] Starting Initialisation...

But then crashed P3Dv4 at:

   157875 LUA.1: LINDA:: [START] Calling Initialisation...
   157875 LUA.1: LINDA:: [START] Path = linda/system/init
   157875 RunLua just called: Filename "C:\P3Dv4\Modules\linda/system/init.lua"
   158031 LUA: "C:\P3Dv4\Modules\linda/system/init.lua": killed

I can not see any of the invalid argument fails. I will run the test again but it will be later.

 

FSUIPC5.log-A

FSUIPC5.log-B

[Scotfleiger]

The attached log is from 20 mins of testing. P3Dv4 did not crash in this test.

There was one example of Invalid Argument at 697000. In this case I restarted before LINDA had completed its initialisation.

In a number of cases, the logging is a little confusing. The debug reports RunLua just called and show init.lua as the filename. I would have expected linda.lua which is killed and a thread created in the 2 subsequent lines.

   694734 RunLua just called: Filename "C:\P3Dv4\Modules\linda/system/init.lua"
   694890 LUA: "C:\P3Dv4\Modules\linda.lua": killed
   694890 About to Create the Lua thread: Entry 1, Filename "C:\P3Dv4\Modules\linda.lua"
   694890 Create Lua thread: Entry 1, Filename "C:\P3Dv4\Modules\linda.lua"
   694890 LUA.1: [START] *********************** STARTING LINDA ***********************

I will be out all day tomorrow.

 

FSUIPC5.log

[Pete Dowson]

6 hours ago, Scotfleiger said:

On both occasions, P3Dv4 eventually crashed at the point RunLua(path) was called on restart.

I need Windows crash details for such things. I've no idea why that would happen, but if pathnames are "disappearing" I suppose the same problem could cause crashes.

This is mch more of a puzzle:

6 hours ago, Scotfleiger said:

    92937 LUA.1: LINDA:: [START] Path = linda/system/init
    92953 RunLua just called: Filename ""
    92953 About to Create the Lua thread: Entry 0, Filename "C:\P3Dv4\Modules\linda/system/init.lua"

The filename is the second line should match the one in the third. The one feeds the other!

Could you have Button/Key logging enabled next time please?  And you can take the LogExtras and TestOptions lines out now, they only make the log unnecessarily larger.

Pete

4 hours ago, Scotfleiger said:

In a number of cases, the logging is a little confusing. The debug reports RunLua just called and show init.lua as the filename.

Aha! That might be a clue to the above. Maybe I've somehow have sourced the string from the wrong place. I'll take a look -- tomorrow.

But you didn't manage to get the original error at all?

After Thursday I am out for 9 days.

Pete

 

[Scotfleiger]

I have attached the 2 reports P3Dv4 crashes from yesterday (1752 and 1759) - logs in reverse time order.

P3Dv4-FSUIPC5103fT2-crashreports.txt

[Scotfleiger]

Further test with all FSUIPC logging off except buttons/keys as requested. No crashes.

One occurrence of Invalid Argument and a number of the different .lua filenames.

FSUIPC5-C.log

[Pete Dowson]

1 hour ago, Scotfleiger said:

I have attached the 2 reports P3Dv4 crashes from yesterday (1752 and 1759) - logs in reverse time order.

P3Dv4-FSUIPC5103fT2-crashreports.txt

Ouch. Crashes in ntdll ... I can't really do much with those. Usuaully, even if I can reproduce them here under a debugger, the call stack is deep and with no sign of anything I can call familiar FS or FSUIPC code.

Did you have any devices being driven then, or is this LINDA in the mode as here, not doing anything?

Pete

 

[Pete Dowson]

1 hour ago, Scotfleiger said:

One occurrence of Invalid Argument and a number of the different .lua filenames.

FSUIPC5-C.log

The variety is something to do with incorrectly sourcing the string for the first added log line, but this is rather odd:

   581688 Create Lua thread: Entry 0, Filename "C:\P3Dv4\Modules\linda/system/init.lua"
   581688 *** LUA Error: cannot open : Invalid argument

That filename in the first line is definitely the one passed to the Lua function which is failing.

I'm a little worried about your use of / instead of \, as there are many places in the original Lua code (and in my code come to that) which do assume that path separators are always \. I know Windows appears to accept it, but conventionally / is used for URLs and \ for file paths. Can you try to repproduce the error using \ only please?

The alternative would be for me to search every path string ever passed to Lua functions to ensire all / characters are replaced by \.

Pete

 

 

[Scotfleiger]

Yesterday's tests with crashes I had P3Dv4, 5.103fT2 and LINDA 3.0.1 running. Possibly AS16. 

Devices were VRI MCP2a, Saitek panels, throttles and CH Flightstick. No buttons were pushed during test. Only CYRL+ALT+R used to restart. 

[Pete Dowson]

1 hour ago, Scotfleiger said:

Devices were VRI MCP2a, Saitek panels, throttles and CH Flightstick. No buttons were pushed during test.

Whether buttons are pushed or not is probably irrelevant. Are there hardware-related programs or drivers running when you Kill the thread responsible for them? As this is the only thing I can think of which might be able to cause the crashes. I'm sure there not related to the problem we are investigating.

On that, here's my final test module, with logging as close as I can get t where it says there's a "" filename (or did do when I added that log line into the base Lua code, now removed). After this test I give up.

FSUIPC5103f_T3.zip

I thought you were out all day today?

Pete

 

 

 

[Scotfleiger]

I'm back!!

I have run repeated tests with 5.103fT3. There were no crashes or invalid arguments.

I initially changed my code to reverse the forward to back slashes (entered as "\\" in strings) for the path used to access my system files. First, this stopped the file_exists() finding the files based on the \modules root. Secondly, the Split function generates an error - this is used to process all the Lua libraries used and built into a long string of file path names separated by the pound/hash sign. Windows is indifferent to whether forward or back slashes are used in pathnames and in most cases does not cause the LuaRun/LuaKill function calls any problems.

FSUIPC5.log

[Pete Dowson]

7 hours ago, Scotfleiger said:

I have run repeated tests with 5.103fT3. There were no crashes or invalid arguments.

Well, the only difference is those extra log lines, which were intended to be temporary.  They must affect the timing but it is a very small difference. Thay's a log of extra log lines each time a Lua is loaded:

    90578 RunLua just called: Filename "C:\P3Dv4\Modules\linda\system\init.lua"
    90578 About to Create the Lua thread: Entry 0, Filename "C:\P3Dv4\Modules\linda\system\init.lua"
    90578 Create Lua thread: Entry 0, Filename "C:\P3Dv4\Modules\linda\system\init.lua"
    90578 Inside the Lua thread: Entry 0, Filename "C:\P3Dv4\Modules\linda\system\init.lua"
...
    90578 Inside the Lua thread: Entry 0, Filename "C:\P3Dv4\Modules\linda\system\init.lua"

I might have to do a process of elimination on those, or just substitute a delay instead of all of them.  But first, because it is presumably because of the Kill action overlapping the fresh load (?) I will double check to make sure the LAST thing the Kill sequence does is free the table entry so it isn't used prematirely by the new thread. It's the only thing I can thing might be occurring.

7 hours ago, Scotfleiger said:

I initially changed my code to reverse the forward to back slashes (entered as "\\" in strings) for the path used to access my system files. First, this stopped the file_exists() finding the files based on the \modules root. Secondly, the Split function generates an error - this is used to process all the Lua libraries used and built into a long string of file path names separated by the pound/hash sign.

All that must be down to assumptions about your / usage made in other Lua program in your portfolio, as I always only ever use \ with never such problems.

Never mind anyway. We know it isn't that. It was only a straw to be clutched! ;-)

Pete

 

 

[Pete Dowson]

One last test. Please try this:

FSUIPC5103f_T4.zip

I've removed the extra log lines, but inserted small delays which should amount to the equivalent -- but only for those preceding the call tghe the loadfile function which exeutes the fopen.

Let me know please.

Pete

 

[Scotfleiger]

Test ran with many restarts with FSUIPC5103fT4. No Invalid Arguments or other problems found.

Well done and thank you.

FSUIPC5.log

[Pete Dowson]

4 minutes ago, Scotfleiger said:

Test ran with many restarts with FSUIPC5103fT4. No Invalid Arguments or other problems found.

Good.

Should I make the same changes to FSUIPC4? Seems strange that this only occurred with FSUIPC5. The code involved for the whole of the Lua facilities is identical. Well, apart from the 64-bit COM handle business, resolved earlier.

Pete

 

 

[Scotfleiger]

I believe the same issue was appearing in FSUIPC4 but was not an issue as I was not performing the multiple restarts I was doing when trying to get my code working with FSUIPC5. For consistency I suggest both FSUIPC variants should be kept the same. 

[Pete Dowson]

29 minutes ago, Scotfleiger said:

For consistency I suggest both FSUIPC variants should be kept the same. 

Yes, I agree. Easier for maintenance too.

Pete