20,741
edits
Troubleshooting crashes: Difference between revisions
Jump to navigation
Jump to search
m
→Debugging Segfaults & Obtaining Backtraces: http://forum.flightgear.org/viewtopic.php?f=25&t=22288&hilit=backtrace+gdb&start=45#p202728
m (→Debugging Segfaults & Obtaining Backtraces: http://forum.flightgear.org/viewtopic.php?f=25&t=22288&hilit=backtrace+gdb&start=45#p202736) |
m (→Debugging Segfaults & Obtaining Backtraces: http://forum.flightgear.org/viewtopic.php?f=25&t=22288&hilit=backtrace+gdb&start=45#p202728) |
||
| Line 242: | Line 242: | ||
And that similarly applies to many things, especially things that "jump" boundaries here. Another prime example is property tree listeners - Nasal listeners don't have a backtrace beyond the C code, even if it is triggered directly from a Nasal setprop()/.setValue(), because it passes through C and C++ stack frames and then back into Nasal. | And that similarly applies to many things, especially things that "jump" boundaries here. Another prime example is property tree listeners - Nasal listeners don't have a backtrace beyond the C code, even if it is triggered directly from a Nasal setprop()/.setValue(), because it passes through C and C++ stack frames and then back into Nasal. | ||
Thus, valgrind/gdb/cachegrind/perftools may be too low-level to be meaningful in most cases, i.e. just look at what's going on in the scenery/aircraft department, here just identifying "hot spots" in terms of code/functions would be a red herring, because the real culprit is typically not at all in the run-time code, but the underlying scenegraph data, such as highly complex textures, 3D models or terrain/scenery. | |||
This can now be easily verified by using Zakalawe's new draw-masks to switch off aircraft/scenery/clouds or AI model rendering. | |||
Having acess to gdb/valgrind etc is one thing, being able to actually run and interpret the results is a completely different thing. | |||
Thus, it is more promising -in the long term- to optionally expose certain info at run-time, so that users can access it to see how their aircraft/scenery/feature/configuration behaves in comparison to some other aircraft/scenery/feature/configuration. | |||
Also, when it comes to using tools like gdb -and especially valgrind- the main challenge is that FlightGear is primarily a GUI application, and it doesn't lend itself it being debugged/profiled or leak-tested in an isolated fashion at all. | |||
For example, for valgrind runs to be useful and straightforward, we would need to be able to minimize what's done inside fg_init.cxx so that we can disable things not needed, but also even run FlightGear in a [[FlightGear Headless|"headless" mode]] without a visible GUI window, so that such tests could be run directly on the build server as part of a regression testing suite. Otherwise, even just running fgfs in valgrind for 10 minutes sim time may turn out to take hours due to the nature of valgrind, i.e. it being an emulator. | |||
valgrind et all are great if you know how to use them, but for end users, these tools are too fine-grained, we would ideally support some per-subsystem or per-feature granularity for end users. | |||
== Related == | == Related == | ||