Okay, I'm currently rebuilding FlightGear without threading support to see what that will do. I don't suspect the threading stuff in particular, but it probably adds quite a bit to the compexity of the debug process. I have a few days off (good friday and easter), so hopefully I can do some more debugging runs. I put some further comments below in the original replies.
Andy Ross wrote: > >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. True. It's my experience though (on projects that are admittedly a few orders of magnitudes simpeler than flightgear) that a gdb stacktrace usually gets pretty close to the offending line of code. Curt wrote: > 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. That's interesting: Does anybody know how I turn off the AI traffic (other that hacking the code). I tried browsing the commandline options but couldn't find one there. > > 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. Well, let's call it a hypothesis; that makes it testable. :-) Your guess would be consistent with my observation that I've seen the abort occur more or less consistently when approaching land after having flown overseas for a while, and approaching land. So another test would be to let flightgear try and do a long haul overland route, over an aera with loads of airports, like a cross-country USA flight, that way, the ref count would almost never get down to zero, and the chances of getting the deadbeef abort would be equally close to zero. > > 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). > Yeah and a particularly funny/appropriate one. A friend of mine described accessing unallocated memory as "poking in dead beef", with all the smelly consequences it has... Cheers, Durk _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
