Hi All,
Thanks to a report by regular Forum poster MD-TERP (a.k.a. Rob), we found a
way to trigger the infamous NaN warning in a rather reliable manner. Following
up on this lead, I modified OpenSceneGraph so that it deliberately segfaults
when the warning message is triggered (I know, I could have set a break point
there in GDB, but I was lazy).
Although I don't have a fix yet, I've collected quite a bit of information
about the problem, and have a pretty good insight as to what's going on.
Rob suggested trying a Flight from KMTN to KSKY, using the Citation-Bravo,
cruising at FL240, enabling AI Traffic, Traffic Manager, ATC, and Multiplayer.
The com1 radio was tuned to KMTN tower (121.3), but this is probably not
relevant. The actual aircraft also probably doesn't matter. Using this setup,
a NaN error is triggered rather reliably while crossing the Pittsburgh area.
OpenSceneGraph was modified to include a deliberately malicious piece of code
designed to trigger a segmentation fault upon printing the error message.
Two stack traces were obtained, and a third one was examined in more detail
using GDB, and saved as a core file.
Stack Trace #1 showed that the warning was triggered inside the AI Traffic
subsystem, in particular in a call to
globals->get_scenery()->get_elevation_m()
Stack Trace #2 showed that the warning was triggered in
src/Environment/ridge_lift.cxx again in a call to get_elevation_m()
So, in conclusion, it looks like the get_elevation_m() is the culprit.
However, it also seemed that the NaN warning was only triggered when AI
Traffic was activated, which seemed to be at odds with it being triggered by
ridge_list as well.
At this point, Mathias Froelich pointed out to me that 3D model objects
included in the scene graph are involved in the ground elevation scanning
process. Mathias also suggested to me that it should be possible to determine
the offending model, by printing out the this->_name variable at various
levels of the stack. Traversing the stack, I found that at least one possible
source of the problem can be found in
Aircraft/c172p/Models/c172p.xml,
more particularly so in the included model
Aircraft/Instruments-3d/mag-compass.xml,
in particular in the the object with the name "Interior". I'm not a 3d
modeling expert enough to determine what could possible wrong in this object.
Mathias suggested that a triangle with a zero sized surface or something like
that could blow the math. If anybody with more expertise than me could have a
look at it, please be my guest.
The fact that an included component of the c172 causes the math of the ground
elevation code to blow perfectly explains why a host of subsystems (at least
in AI Traffic itself, and in ridge_lift) are vulnerable to this error, while
disabling AI Traffic does not affect these other system. By placing a c172
model in the scene, AI Traffic creates a vulnerability, not only for itself,
but also for other systems. Although I haven't seen an error triggered by
traffic generated by the traffic manager (which is, I stress once again, an
entirely separate system), this is probably coincidental, and due to the fact
that we currently don't have much Traffic Manager related activity in the test
area, and therefore the probability of seeing an error generated by the
traffic manager is, in this particular case, low.. Had traffic schedules
involving the c172 model existed, the traffic manager would likely have caused
a similar error/vulnerability itself.
So, to conclude, the mag-compass.ac instrument should be checked for possible
modeling errors.. Also, I would suggest that a meaningful message could be
printed by the ground elevation code in case of an error, so that future
errors could be avoided. This probably can't be done in FlightGear, because it
would require some modification of the OSG code.
Until a full fix is in place, a special purpose AI c172 model could be
created, which doesn't contain the interior. Users not regularly flying the
c172 could remove the 3d compass, so that it becomes usable again as an AI
aircraft.
Obviously, I can't rule out that there aren't more possible causes for the NaN
warning, however. given that it's occurrence seems to be strongly related to
activating AI Traffic, I suspect they are caused by a relatively narrow set of
circumstances.
Cheers,
Durk
------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables
unlimited royalty-free distribution of the report engine
for externally facing server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
