Curtis L. Olson wrote: > Andy Ross wrote: > > >Durk Talsma wrote: > > > > > >>It looks like the crash is somewhere inside the AIMgr (judging from stackdump > >>item #15), but since I'm still incredably unfamiliar with this part of the > >>code, this might just be a wild guess. > >> > >>Anyways, I hope that this is useful debug information. Can others > >>confirm this? > >> > >> > > > >The 0xdeadbeef assertion failure in ssg is almost certainly memory > >corruption. Other typical symptoms are heap corruption, which is what > >seems to be happening here (the crash happens under operator > >new). There's no particular reason to suspect the AIMgr in > >particular, it was just unlucky enough to be the first to traverse the > >broken ssg node. > > > >This kind of bug is really hard to track down. Valgrind helps, but it > >would take *days* to get to where you are seeing the crash. > >Basically, you end up having to search the configuration space: > > > >+ What was the last version that worked? > >+ Does turning off threads fix the problem? > >+ [Ditto for any other configuration choices you have made] > >+ How about changing plib versions? > > > >Some things can be ruled out already: since this is a YASim aircraft, > >JSBSim is off the hook. Likewise, the 747 has no 2D panel, etc... > > > > > > I believe that the AI stuff can be turned off, so you could run with it > off and see if you see a crash or not. > > As I understand it, the deadbeef thing is something ssg writes into > memory that it frees. Later if you try to traverse something that is > marked as deadbeef, you know you have a pointer to deallocated memory. > This is typically what triggers the deadbeef assertion. > > My guess (and this is a guess) is that the ai system is loading a single > model of an aircraft and using it in multiple places. Then, if for > some reason all the aircraft of a certain type fly out of range and we > remove them from the tree, ssg could try to free the model itself if the > last reference to it is removed. > > But, if the ai system doesn't account for this and later tries to use > that same model pointer, you will get the deadbeef error (notice > deadbeef is a hexidecimal number). > > What you do to work around this problem is to ref() the model once when > you load it, then you can add and remove it from the scene graph as much > as you like, delete the parent of the model, etc. etc. and the number of > references will never drop below one, so the model itself will never be > deleted. > > That's pure speculation though based only on the crash appearing to > happen in the AI system.
Indeed, I don't see _defaultModel->ref(); or _piperModel->ref(); in AIMgr.cxx -Fred _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
