20,741
edits
Troubleshooting crashes: Difference between revisions
Jump to navigation
Jump to search
m
→Debugging Segfaults & Obtaining Backtraces
| Line 159: | Line 159: | ||
=== Debugging Segfaults & Obtaining Backtraces === | === Debugging Segfaults & Obtaining Backtraces === | ||
{{Note|This section is currently Linux/gdb specific}} | |||
A '''segfault''' is another word for "crash", it's a so called "segmentation fault". In order to see what was going on when the crash occurred, you'll need to build a binary with debugging symbols enabled, usually this includes FlightGear and SimGear - and possibly even OSG (OpenSceneGraph, only if your crash happens inside | A '''segfault''' is another word for "crash", it's a so called "segmentation fault". These will typically happen due to coding errors, either in FlightGear or one of its dependencies (libraries like SimGear, plib, OpenSceneGraph or OpenAL). In order to see what was going on when the crash occurred, you'll need to build a binary with debugging symbols enabled, usually this includes FlightGear and SimGear - and possibly even OSG (OpenSceneGraph, only if your crash happens inside rendering related code). | ||
A | A so called '''backtrace''' is basically pretty much like a flight data recorder that is used to conduct a post-crash analysis. | ||
A binary with debugging symbols included will contain additional information that helps developer track down what is causing a certain crash, such as for example the file name, function, line number, variable that was accessed before the crash happened. This is analogous to how a FDR/CVR on an airplane records certain parameters like position, orientation, altitude, velocities, configuration, cockpit conversations etc. | |||
Debugging FlightGear crashes is significantly simplified by having access to such runtime data, because we can basically go back in time and see what the FlightGear program was doing shortly before the crash. | |||
Unfortunately, logging all this data by default has a certain runtime overhead, so it is usually too costly and not done, FlightGear will by default be heavily optimized by your compiler and not include code logging important debugging/post-crash parameters, for the sake of performance. | |||
Thus, you'll want to reconfigure your SimGear/FlightGearGear ($SG_SRC & $FG_SRC) source trees using the '''-CMAKE_BUILD_TYPE=Debug''' switch, for details please refer to: [[Building using CMake#Debug_Builds]]. It is a good idea not to touch your existing build trees for this, but instead create an additional directory hierarchy for your debugging binary, please see [[Building using CMake#Multiple build directories]] for details. | |||
Once you have rebuilt and relinked SimGear and FlightGear, you'll want to use a debugger like '''gdb''' to run your new binary. It does help to have a good way to reproduce a crash, such as using certain startup/runtime settings. For the sake of simplicity it is usually a good idea to disable all unrelated features and subsystems/settings, this includes complex aircraft and complex scenery locations (airports) if possible. For details, refer to the minimal startup profile detailed in this article. | Once you have rebuilt and relinked SimGear and FlightGear, you'll want to use a debugger like '''gdb''' to run your new binary. It does help to have a good way to reproduce a crash, such as using certain startup/runtime settings. For the sake of simplicity it is usually a good idea to disable all unrelated features and subsystems/settings, this includes complex aircraft and complex scenery locations (airports) if possible. For details, refer to the minimal startup profile detailed in this article. | ||