Howto:Troubleshooting using git bisect
| This article is a stub. You can help the wiki by expanding it. |
This article document how to troubleshoot using Git bisect in the context of FlightGear.
Setting up ccache
Running git bisect will inevitably mean that each source tree will need to be rebuilt, so it is recommended to install, and use, ccache.
Typically, all you have to do on a Linux system is invoking your package manager and pass "install ccache" to it.
When reconfiguring the FlightGear build tree via cmake, you should see ccache being used
Coming up with a wrapper script
 |
Work in progress This article or section will be worked on in the upcoming hours or days. See history for the latest developments. |
First, we need to come up with a script for building FlightGear and its dependencies, this can typically be done using an existing build tree for sg/fg, e.g. using the Superbuild or the download and compile script
Use Case: broken logging
|
|
Currently there is a seg-fault(crash) if you try to record multiple log files, this is a good idea if you want to have seperate logging intervals for each paramater. BUT it does not work :( even though in the documentation its reported as allowed.
apparently, the third entry (actualy n="2") is the one that causes the crash, that entry is related to the performance monitor, regardless, even if i omit that entry(keep only n="0" and n="1"), Flightgear does not record to multiple files, only one log is recorded if ran successfully, and the second log is generated but contain only time and <title> headers in the first line and the rest of it is empty, anyway, here is my xml file
--config=boom.xml
with boom.xml containing this:
<PropertyList>
<logging>
<log n="0">
<enabled type="bool">true</enabled>
<interval-ms type="long">1000</interval-ms>
<filename>frameSpacing.csv</filename>
<delimiter> </delimiter>
<entry n="0">
<enabled type="bool">true</enabled>
<title>frameSpacing</title>
<property>/sim/frame-latency-max-ms</property>
</entry>
</log>
<log n="1">
<enabled type="bool">true</enabled>
<interval-ms type="long">1000</interval-ms>
<filename>actualFPS.csv</filename>
<delimiter> </delimiter>
<entry n="0">
<enabled type="bool">true</enabled>
<title>actualFPS</title>
<property>/sim/frame-rate</property>
</entry>
</log>
<log n="2">
<enabled type="bool">true</enabled>
<interval-ms type="long">1000</interval-ms>
<filename>nasalTotal.csv</filename>
<delimiter> </delimiter>
<entry n="0">
<enabled type="bool">true</enabled>
<title>nasal-total-ms</title>
<property>/sim/performance-monitor/subsystems/subsystem/total-ms</property>
</entry>
</log>
</logging>
</PropertyList>
#1 0x0830460f in FGLogger::Log::~Log() ()
#2 0x083059ea in std::vector<FGLogger::Log, std::allocator<FGLogger::Log> >::_M_insert_aux(__gnu_cxx::__normal_iterator<FGLogger::Log*, std::vector<FGLogger::Log, std::allocator<FGLogger::Log> > >, FGLogger::Log const&) ()
#3 0x08304f26 in FGLogger::init() ()
#4 0x08d028bf in SGSubsystem::incrementalInit() ()
#5 0x08d03398 in SGSubsystemGroup::incrementalInit() ()
#6 0x08d02c94 in SGSubsystemMgr::incrementalInit() ()
#7 0x0830754d in fgIdleFunction() ()
#8 0x08889189 in fgOSMainLoop() ()
#9 0x08306405 in fgMainInit(int, char**) ()
#10 0x082c9cf7 in main ()Coming up with a test script
Next, we need to come up with a script to tell git bisect if the binary is working as expected or not. Given that the logging file shown above will trigger a segfault, we can either run fgfs inside a gdb session or directly invoke fgfs via the test script:
segfault-logging.gdb:
file src/Main/fgfs
run --config=boom.xmlbisect-test.sh:
rebuild && gdb -batch --command=segfault-logging.gdb -return-child-result
cd $FG_SRC
git bisect start -- src/Main/logger.cxx
git bisect bad
git bisect run bisect-test.sh
- https://robots.thoughtbot.com/git-bisect
- http://www.clock.co.uk/blog/git-bisect-simple-examples-and-automation
- https://lwn.net/Articles/317154/
- https://git-scm.com/docs/git-bisect
Narrowing down things using release tags
To make things easier, I would only git bisect using actual release tags to nail things down for starters - so that you can easily have sg, fg and fgdata in sync. Once you have a test case, you can leave git bissect running unattended (e.g. over night). If you have ccache set up on your system, building sg/fg should be relatively fast, even when running git bissect