Menu
▾
▴
#2127 2019.1.1 & 2019.2.0 segfault on reset
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.
Thanks, it's hanging in something rleated to Richard's new Emesery notifier. @r-harrison did you test reset was working okay for you after adding the transmitter? I think we might need to explicityl shut it down on reset.
I haven't yet had a chance to look into this.
I suspect that the global transmitter should not be deleted during reset; just ensure that all registered recipients de-register on destruction.
Yeah, I figured it out, testing a patch now.
Pushed some tweaks to next (needs both SG & FG) : let me know if this improves things, Bjoern.
Will do tomorrow. Thanks for the quick fix!
No dice. :(
1) Launch FG session
2) Wait until everything has finished loading
3) "File" --> "Aircraft Center"
4) Pick new aircraft
5) Hit "Fly"
6) FG freezes after a short while and has to be forcefully terminated
GDB backtrace:
Last edit: Bjoern K 2021-06-18
FGFS log:
Same result when issuing "File" --> "Reset".
FGFS.log
Hmm, this must be a Linux-ism. A 'bt all' would help but it seems shutting down / re-joint the exclusive thread isn't working there. But I'll try a build on an Ubuntu VM in the next few days, unless @rharrison beats me to it.
The primary "Linuxisms" I can think of is differing directory separators for paths and too strict handling of folder naming (as in capitalization).
Or it's an OSG bug.
I've got all FG files with me this week, so I can build it on my laptop to rule our graphics driver related issues (laptop: NVidia, desktop: AMD).
Having just fixed the shutdown hang, reset works for me on Ubuntu (at BIKF, with the UFO, using SingleThreaded OSG)
Still getting crashes. Aerostar 700 at BIKF. Multiple resets at the location were okay, but changing the airport to EDAH and then resetting crashed FG.
P.S: Do you know how to pass that "handle SIG32 nostop" command at startup? Having to look it up and copy and paste it for each debugging session is highly annoying.
Last edit: Bjoern K 2021-06-25
Is anyone able to reproduce this issue on 2023.x or 2024.x? Without any further information or updates perhaps it should be marked as stale/closed.
These crashes typically rleate to OSG multi-threading mode. We had a bug (which Stuart fixed) that we ignored the multi-threading mode of the OSG DB pager on first init but on second init (i.e reset) we applied the value correctly.
This meant a whole bunch of thread crashes/race conditions only showed up after reset. Stuart has fixed some but some remain, but anyway we now know reset is not to blame, it's multi-threading. So tnhis can be closed.