20,741
edits
Troubleshooting crashes: Difference between revisions
Jump to navigation
Jump to search
→Debugging Segfaults & Obtaining Backtraces
m (→Reporting incompatible default settings: http://forum.flightgear.org/viewtopic.php?f=18&t=22770) |
|||
| Line 159: | Line 159: | ||
=== Debugging Segfaults & Obtaining Backtraces === | === Debugging Segfaults & Obtaining Backtraces === | ||
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 rendernig related code). | |||
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. | |||
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. | |||
== Related == | == Related == | ||