20,741
edits
Troubleshooting crashes: Difference between revisions
Jump to navigation
Jump to search
→Debugging Segfaults & Obtaining Backtraces
| Line 161: | Line 161: | ||
{{Note|This section is currently Linux/gdb specific}} | {{Note|This section is currently Linux/gdb specific}} | ||
A '''segfault''' is another word for "crash", it's a so called "segmentation fault", where the program is doing things that it wasn't designed to do, such as accessing invalid memory for example, so that the operating system will terminate the process because its behavior is no longer valid. These will typically happen due to coding errors, either in FlightGear or one of its dependencies (libraries like SimGear, plib, OpenSceneGraph or OpenAL | A '''segfault''' is another word for "crash", it's a so called "segmentation fault", where the program is doing things that it wasn't designed to do, such as accessing invalid memory for example, so that the operating system will terminate the process because its behavior is no longer valid/correct. These '''segfaults''' 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/included, usually this includes FlightGear and SimGear - and possibly even OSG (OpenSceneGraph, normally only if your crash happens inside rendering related code). | |||
A binary with debugging symbols included will contain additional information that helps | A so called '''backtrace''' is basically pretty much like a flight data recorder tape/log that is used to conduct a post-crash analysis. | ||
A binary with debugging symbols included will contain additional information that helps developers track down what was 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. This can also be used by developers to see who is responsible for a certain segfault/bug, i.e. which commit introduced the bug. | |||
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. | 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 | Unfortunately, logging all this data by default has a certain run-time overhead and requires additional tools and knowledge, 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 better performance. | ||
However, as developers, we do appreciate all efforts to provide meaningful bug reports, and a reproducible bug including a good crash analysis, i.e. a so called '''backtrace''' is as good as it gets, and the likelihood of a certain bug being examined and fixed is significantly higher when the bug report includes both, a '''backtrace''', and a set of steps to reproduce the error reliably. | |||
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. | 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. | ||