Hello,
I have been compiling the tags 2019.1.1 on simgear, flightgear, flightgear-data, as well as next branch, and they all segfaults when clicking on "Restart" in the fg gui menu.
I have compiled them against latest OSG-3.6.3.
Let me know if you need more details.
Cheers,
Chris.
I also see this. I cleaned out the directory pointed to by FG_HOME, and I can reset one time okay. If I reset more than once, FG crashes.
Will take a look at this, thanks for the report.
For me it crashes on the first time - it's a Nasal GC issues, so you migth get lucky and not crash depending on the timing, but sooner or later it will crash indeed. Need to discuss with Richard.
More than likely related to the instrumentation(probably getting the filename) that I added to the GC - I'll revert this and hopefully it'll fix it.
I think it might have been crashing for longer than that, but let's find out....
FWIW I don't get (and don't recollect getting) any crash when doing File->Reset or Shift-ESC (Win64, next, OSG 3.4 (fg))
Still crashes for me with your revert, unfortunately. So we need to look. a little further back.
This is still happening with 2019.2.0 (on Linux). Reproduced with anything that involves resetting like changing to the Launcher from the simulator and clicking "Fly Now" or hitting Shift+ESC.
Git log output:
fg:
commit 22de9d30b518646894ac190cc6b04371daa6d5c2 (HEAD -> next, origin/next, origin/HEAD)
sg:
commit d5957b8c5f2188674eb6b3d480bd8eb70d253f79 (HEAD -> next, origin/next, origin/HEAD)
Built against OSG 3.6.4.
Attached is the fgfs.log and a GDB trace.
Last edit: Bjoern K 2019-11-27
I can't reproduce this issue with next today - can anyone here reproduce it now?
Just recompiled the latest Next and the problem persists.
Tested in two different ways. GDB output files, including "bt full" info, are attached.
1) Started flight; hit "Reset" from the menu (gdb.log)
2) Started flight; selected "Aircraft Center" from the menu; picked a new starting location; hit "Fly" button (gdb_launcher.log)
Last edit: Bjoern K 2020-03-11
Bjoern, can you try the first test again, but before run-ing, enter 'handle SIG32 nostop' in gdb? At the moment the SIG32 is stopping us seeing what the real ssue is, I think.
Here you go.
Note that I repulled and rebuilt OSG and FG before I tested.
Bjoern, is there a particular reason you're using OSG 3.6 as oppsoed to 3.4? Some other features are broken with 3.6, so I only test with 3.4, and that's what we use for the official binaries.
OSG 3.6.5 is the only release in Arch's repositories. The Git package is at version 3.7.0+ by now.
Please re-test on next with commits 297e5095762be2fc0fe7995f7115e2e58edb09ae (SimGear) and 06e6883396fef04caf8e6c54d1874de2b5581644 (flightgear) - will hopefully make a difference.
Still not fixed. The aircraft in use does not matter.
FG commit: c8d5296f7bef162311a303ff904577b4010c5e80
SG commit: 9ec9d8e4233f9f8a03e3ad6a0525ce47d34d4c9d
GDB log: See attachment.
P.S: I also noticed that, when called from within a session, the Aircraft Center does not list all my installed aircraft, only those downloaded from the launcher. It's as if the path to my add-on airecraft folder is completely ignored. But this is probably another bug.
Fgfs.log for my last report.
Ah, SIG32 is a false-positive, due to us cancelling the voice thread on reset. Can you do 'handle SIG32 nostop' in your GDB session before running FG, and then repeat the test run? That should give us the real back-trace.
Sure, here you go.
Nota bene: This uses
--prop:/sim/rendering/multithreading-mode=CullDrawThreadPerContextto check if it's a potential fix for this segfault.FGFS log:
I've compiled a debug build (FG HEAD c8d5296f7bef162311a303ff904577b4010c5e80, SG HEAD 9ec9d8e4233f9f8a03e3ad6a0525ce47d34d4c9d), but when trying to reproduce this bug now, all FG does is hang at "Finalizing Position", requiring issuing a SIGINT (CTRL+C).
Not sure if the associated backtrace yields something useful:
FGFS.log: