Curtis L. Olson writes: > David, I'm looking for help on this one since it's seems to be very > much wrapped up in the property system and environment manager and > cloud layers. > > This problem seems to be very complicated.
Agreed. I've managed to patch things up in my local copy so that it consistently crashes on the second reset rather than the first, for what it's worth, and the presence or absence of the clouds config no longer makes any difference -- I think that it was just triggering the bug faster. It's going to take me a while to test this (and to understand the logic flow), but here's my current hypothesis: when FlightGear is reset, some modules are replaced with new ones (the old ones may or may not be deleted, but are never unbound). We end up with all kinds of dangling references, especially (but not exclusively) for bound properties, and eventually things grind to a halt. If I'm right, the property module makes the crash happen sooner, but the crash *will* happen one way or another, and there are probably some nasty memory leaks in there as well. Remember that reset has always caused occasional unexplained, hard-to-reproduce crashes. The long-term fix is to finish the cleanup of main.cxx and fg_init.cxx so that all initialization code is moved out to the subsystems, and the subsystems themselves are kept in a single, ordered list so that they can be managed easily and transparently. It should not be necessary to delete and replace any subsystems on a reset, with the exception of the FDM, since all can adjust their state as required. The short-term fix is harder to guess; it will depend on what we all find while digging around. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
