Hi fellow wiki editors!

To help newly registered users get more familiar with the wiki (and maybe older users too) there is now a {{Welcome to the wiki}} template. Have a look at it and feel free to add it to new users discussion pages (and perhaps your own).

I have tried to keep the template short, but meaningful. /Johan G

Howto:Debugging Properties

From FlightGear wiki
Jump to: navigation, search
This article is a stub. You can help the wiki by expanding it.

1rightarrow.png See Resource Tracking for FlightGear for the main article about this subject.

Some basic property-debugging support to FlightGear and SimGear. In FlightGear, the --trace-read option causes all read access for a property to be traced, and the --trace-write option causes all write access for a property to be traced, both through SG_LOG messages.

Tracing a popular property like /position/altitude will cause a lot of output and will slow down FlightGear, but presumably, you're debugging anyway so you won't mind.

The neatest part of all this is that it allows you to debug properties and C++ code together in a regular debugger. The --trace-read property causes SGPropertyNode::trace_read to be invoked, and the --trace-write property causes SGPropertyNode::trace_write to be invoked.

Let's say that you wanted to find out what parts of the C++ code are setting the /foo/bar property. You would load FlightGear into a debugger, set a breakpoint on SGPropertyNode::trace_write (in simgear/simgear/props/props.cxx in the SimGear distro), then run the program with the following option:

--trace-write=/foo/bar

Every time any code sets a new value for /foo/bar, you'll hit your breakpoint, and you can look at the backtrace to find out where it is being set.

You need the trace feature for debugging user configuration, not just C++ code. Again, think of FlightGear as analogous to a word processor or spreadsheet: users will always be loading new kinds of data -- designing new panels and flight models, scripting events, creating scenarios, etc. etc. The trace feature gives some (pretty minimal) support for design, testing, and debugging their work.

Cquote1.png I hacked my copy of FlightGear to loop through property accesses multiple times and watched the framerate. Here's what I got, using the lower value whenever the framerate fluctuated:
  1. No extra accesses: 44fps
  2. 500 SGPropertyNode pointer accesses per frame: 43fps (2.3% slowdown)
  3. 500 fg(Get|Set)* accesses per frame: 42fps (4.5% slowdown)
  4. 1,000 SGPropertyNode pointer accesses per frame: 42fps (4.5% slowdown)
  5. 1,000 fg(Get|Set)* accesses per frame: 40fps (9% slowdown)
  6. 10,000 SGPropertyNode pointer accesses per frame: 27fps (39% slowdown)
  7. 10,000 fg(Get|Set)* accesses per frame: 22fps (50% slowdown)
The surprise here is that most of the loss comes not from the map lookup (which is skipped by the SGPropertyNode pointer access) but from the SGPropertyNode::getValue itself: at 10,000 accesses, the first 39% of the overhead comes from getValue, and only the remaining 11% from the map lookup. That's just wrong, but it's also good news, because the map lookup should be easy to fix -- I'm doing a profiling build now to help me hunt down the problem. So far, we're making far fewer than 500 property lookups per frame, so there is no noticable drop, and you may be just as well off using fg(Get|Set)* directly for now.
— David Megginson (Tue, 26 Feb 2002). re: [Flightgear-devel] Property Access.
Cquote2.png

Also see