Troubleshooting crashes: Difference between revisions

Jump to navigation Jump to search
m
→‎Debugging Segfaults & Obtaining Backtraces: http://forum.flightgear.org/viewtopic.php?f=18&t=23985&p=217779#p217779
m (→‎Debugging Segfaults & Obtaining Backtraces: http://sourceforge.net/p/flightgear/mailman/message/32749837/)
m (→‎Debugging Segfaults & Obtaining Backtraces: http://forum.flightgear.org/viewtopic.php?f=18&t=23985&p=217779#p217779)
Line 211: Line 211:
* screen shots showing frame rate, frame spacing, performance monitor, osg on-screen stats (see [[Howto:Use the system monitor]] )
* screen shots showing frame rate, frame spacing, performance monitor, osg on-screen stats (see [[Howto:Use the system monitor]] )
* use the about dialog to provide other important information
* use the about dialog to provide other important information
== Troubleshooting Performance Issues ==
If you're able to build from source and don't mind using development looks like the built-in profiler, it would be interesting to see comparison of both builds - ideally using a simple test case with everything else disabled - you could use a pre-recorded flight and/or a flight recorder type to come up with a "test flight". From our standpoint, it would help tremendously if all features that don't seem to have an effect could be completely disabled, including complex aircraft and scenery/locations. In other words, if you can reproduce the problem using "bare" minimum settings, the resulting log file will be much easier to process.
There's a built-in profiler which you can use to create these profiles: http://wiki.flightgear.org/Built-in_Profiler
You would then want to use two different build directories, where SG/FG build settings would be identical, but using an older version of OSG: http://wiki.flightgear.org/Building_using_CMake#Multiple_build_directories
For the sake of simplicity there's a so called "minimal startup profile" that you can use: http://wiki.flightgear.org/Howto:Debugging_FlightGear_Crashes#Minimal_startup_profile
While unlikely, it would be great if the issue could be reproduced that way - but more likely than not, you'll have to re-add a few features and change a few settings, e.g. by using a different location.
Like I said, you could then use the replay system to create an test flight than can be easily reproduced - to get going more quickly, you can also use the built-in route manager to create a simple flight plan and fly the whole thing on autopilot: http://wiki.flightgear.org/Instant_Replay
You can use time warp mode to speed up simulation time and finish more quickly.
Admittedly, all this may seem a bit intimidating and tedious, but once you have such a setup working, you can reuse it over and over again for different startup profiles and provide profiling logs for each.
We do have a number of people interested in adding features to support benchmarking/profiling workflows natively:
http://wiki.flightgear.org/FlightGear_Benchmark
http://wiki.flightgear.org/Testing
If that's something you'd like to pursue, feel free to get in touch - it is definitely a worthwhile thing, even regardless of any OSG specific issues, as it will also help with unrelated performance issues.
Obviously, there's a bit of a steep learning curve involved, which is why it's normally only core developers that build multiple versions against different OSG versions and run the profiler.
But once you are able to build from source, you have already completed the most difficult step - everything else is fairly straightforward in comparison - as as you can probably tell, creating test flights using the route manager and/or flight recorder also isn't exactly rocket science.
However, before you do anything, I'd suggest to check first if you've possibly changed your driver, or if you can install a newer version


== Debugging Segfaults & Obtaining Backtraces ==
== Debugging Segfaults & Obtaining Backtraces ==

Navigation menu