Tracking down a kernel bug with git bisect

There is this LWN article (that I wrote about it):

http://lwn.net/Articles/317154/

I've successfully used "git bisect" in situations in which, as part of every test, I had to "git stash pop" some local changes, then do the test, then remember to "git stash save" them before continuing to bisect. (Alternatively, "git apply" the stash, then "git reset --hard" to blow away the changes.) That's how you can handle situations where test code has to be added to the program to demonstrate the problem, and that test code doesn't exist in old versions.

The whole idea of bisection is that you have an objective behavior that has changed. If the test (which is, by definition, the tool used to measure that objective behavior) is not constant across the range of changes, then you simply don't have a problem that can be solved by bisection. You're breaking rule one ("This bug" isn't a single behavior).

Obviously in practice you'd probably just use whatever the most recent version of the test is.

Really I think you're problem is that you're overspecifying rule 2. It's not about identifying a "unit test" per se, it's about identifying any specific process to detect the bug. If the tests in your tree work, great. If not, you may have to do a little development to make one that is automatable.

In the past, I've committed the unit test like you, branched, rebased the unit test back to some appropriate point in time, and then run git bisect. This avoids applying/resetting at each step, and allows for some trickiness like changing your test to deal with an interface that mutates over the range of commits you're testing. The hash of the errant commit will be different after rebasing of course, but it's easy enough to match it up with the one in the original branch.

I wish there were a guide or some official "this is how to manage your git repository along with your tests so bisect will work wonders" - IIRC, bisect gets tripped up by commits that won't build and also some merges... would be nice to know what exactly to do about those once they're in your history.

In cases like this I usually copy the relevant test file to somewhere outside the repo, and refer to that path directly in the bisect cmd. That way you don't have to worry about anything conflicting with the new test that you need for the bisect.

E.g. for a Rails app, I might end up using a command like `rspec ~/Desktop/my_new_test_spec.rb`.

I think it works ok if you make a new branch from a known good commit, add the test, then rebase the new changes on top. You could do that with

git checkout -b testing git rebase -i HEAD~50 (or whatever) move test commit to bottom, then save.

You generally create the test in a new file that won't be affected by checking out older code. If you need to change some part of your build system or test system, have the test be a patch that can be applied, run the build, run the tests, and check the results.

As far as having other uncommitted changes; just stash those. "git stash" is a tool you should use very often for any time you have uncommitted work that you need to clear out before doing some other git operation.

> I know you can automate running a shell script, but I don't write my automated tests in shell script.

Your tests aren't a shell script, but certainly you can compile and run your tests from a shell script.

You don't need to commit your unit test... you can run any script from any path.

git bisect run my_script arguments

Sounds challenging. If it's something that happened a lot, you could keep the test suite in a separate repo with API levels, such that tests need newer APIs go in a higher numbered folder (think database migrations in web frameworks) and create a simple run script.

The idea of bisect is that you only need to do log_2(n) steps to find a bug in "n" commits. Even if you have to do manual testing, it's still normally pretty fast, unless you have hundreds and hundreds of commits.

Perhaps you could commit the unit test in a separate commit, then `git cherry-pick` it as a part of the script?

The bisect pointed at the right patch series which is already very nice.

If the bisect script fails because of another problem, it is often possible to refine the script, or run bisect again on a fixed up branch.

You mean "git bisect skip". There is no "ignore" sub command.

I have no idea why people are downvoting you. Sigh.

A comment as to why you're wrong by the downvoter(s) would be infinitely more helpful.

kgdb, kdb, systemtap, ktap, perf, ftrace, ...