I noticed signs of serious Nasal corruption in 2020.3.
After a 2:30-something flight:
1.
HUD cycle / brightness stops working, errors:
8291.57 [ALRT]:nasal Nasal runtime error: No such member: HUD 8291.57 [ALRT]:nasal at /input/keyboard/key[72]/binding, line 1
2.
AI jetways only spawn one jetway in the destination airport, which does not respond to clicks.
3.
Local Weather starts making a strong wind that does not seem to match METAR (Only maybe, because that weather could actually have been there, somehow unnoticed. But after restart, they were not there anymore.).
Relevant settings:
nasal-gc-threaded
: false,
OSG multithreading mode: CullDrawThreadPerContext
.
Affects 2020.3, as of 2021-11-05. Version info:
FG 3965e5986 2021-09-06 | Allow aircraft directory name validation. [James Turner] SG 631fa624 2021-08-20 | Michael Danilov: Fix issue #2169 Sound with condition=false will play when moving into its max-dist (patch available) [Erik Hofman] FGDATA 226290f8b 2021-11-05 | keyboard.xml: remove duplicate commands (fix by Benedikt Hallinger) [Michael Danilov]
There are a few local patches and commits that I have cherry-picked into my local setup on top of that, but they do not seem to have anything to do with Nasal interpreter.
Diff:
Diff:
Diff:
It's good to have a ticket to track this. It happens much quicker with threaded Garbage Collection enabled. And it shows up for core modules sometimes as well.
Are those related? Could the disappearances be the same, but messages about them be different because of those things accessing the object differently?
https://sourceforge.net/p/flightgear/codetickets/2356/
https://sourceforge.net/p/flightgear/codetickets/2641/
Last edit: Anonymous 2021-11-15
Yeah my suspicion is there are all a very infrequent, very random 'some structures get modified' bug. I can't prove it of course.
Unless we can find a valid way of reproducing the problem I think the next logical step is to remove all my changes related to the background GC; because I may have caused a regression.
I spent many days trying to figure out how to improve or reimplement the GC and made no progress it's all very much a mess of entwined dependencies and logic all very much old style C from the age when the code was written; and that failed to figure it out.
Richard, I guess that is logical but seems an unfortunate step. Can we #ifdef your changes to avoid actually backing them out, maybe?
I second the #ifdef'ing: it would be a shame to lose so much work because of a single hard-to-debug glitch.
Because the most important thing is reliability I've now removed the threaded GC; changes in 360c64c7 and 83eda095 by manually reverting the changes to gc.c and code.c - but the rest of the support remains in FlightGear but is commented out and it should be possible to bring it back.
@mike402 can you build this and see if you can break it.
If we can ascertain whether or not this is the cause we can then decide what to do next.
Last edit: Richard Harrison 2022-03-13