[lang]

Present Perfect

Personal
Projects
Packages
Patches
Presents
Linux

Picture Gallery
Present Perfect

git bisect

Filed under: GStreamer,Hacking — Thomas @ 4:46 pm

2009-6-1
4:46 pm

Today I finally had a reason to be happy about GStreamer having switched to GIT.

I added actual encoding support to my CD ripper this weekend. I’m only supporting lossless encoding for now. Sadly, in practice it seems the FFMpeg ALAC encoder crashes, and the wavpack one hangs for me, so I’m left with .wav (meaning no compression) or .flac

And then today I realized that some of my encoded .flac files had a strange bug in them. I wasn’t sure where it was coming from, but some of my encoded files didn’t play with mplayer, gave an error when using flac -d, but still worked completely fine with GStreamer and totem.

I first tried to find a different file from the GStreamer media testsuite to reproduce the symptom. south.mp3 and benow.mp3 owrked fine, but sugar.ogg reproduced the problem.

I also tried it with my installed version (0.10.8, while git master is at 0.10.15.1) and that worked fine.

So that gave me two points to bisect inbetween.

Then I read up on git bisect, and started playing with it. It isn’t particularly nice to do by hand; most checkouts change enough of the autotools files that it has to rerun them most of the times. Then configure changes win32/common/config.h which generates a local change. The common submodule also gets in the way. I got away with just compiling the flac plugin with make -C ext/flac before each test, so that sped up things. But there’s definitely potential for human error.

Basically, you start by doing git bisect start; git bisect bad; git checkout (known good commit); git bisect good

This will leave you somewhere in the middle between the bad and the good commit. Rebuild, do your test, then either type git bisect bad or git bisect good based on the test result. Repeat until you’re at the last commit.

That helped me find where the bug happened (see the bug report).

Of course I wondered immediately if I could automize this, since I wanted to make sure that the same commit broke my original files and I do not want to do that manual bisection again…

It turns out you can; that’s what git bisect run is for.

So, given the following two shell scripts:

test.sh

#!/bin/bash

git submodule update

make -C ext/flac

# rebuilds can touch these files leaving you with local changes
git checkout win32/common/config.h

gst-launch -v filesrc location=/home/thomas/gst/media/medium/sugar.ogg ! oggdemux ! vorbisdec ! audioconvert ! audio/x-raw-int,width=16,depth=16 ! flacenc ! filesink location=test.flac
flac -d test.flac -f
# flac -d exits with 1 when it fails
exit $?

and bisect.sh:

#!/bin/bash

git bisect start
git bisect bad
# 0.10.8 release
git checkout c186d67f40827be349f97d810a45243c874b73f7
git bisect good
git bisect run ./test.sh

I can now just run ./bisect.sh and it will do the whole process automatically.

Try it if you’re curious on a checkout of gst-plugins-good. Change test.sh to point to your sugar.ogg file (which you can get from GStreamer’s test repository).

At the end, the output should show something like:
df707c666433a78d3878af6f055698d5756226c4 is first bad commit
commit df707c666433a78d3878af6f055698d5756226c4
Author: (HIDDEN TO PROTECT THE GUILTY)

The ‘run’ command really is what makes the bisection useful for me. Now, back to bug fixing….

5 Comments »

  1. from man git-bisect:

    [Cutting down bisection by giving more parameters to bisect start]

    You can further cut down the number of trials if you know what part of the tree is involved in the problem you are tracking down, by giving paths parameters when you say bisect start, like this:

    $ git bisect start — arch/i386 include/asm-i386

    […]

    [Bisect run]

    If you have a script that can tell if the current source code is good or bad, you can automatically bisect using:

    $ git bisect run my_script

    Note that the “run” script (my_script in the above example) should exit with code 0 in case the current source code is good. Exit with a code between 1 and 127 (inclusive), except 125, if the current source code is bad.

    Comment by Benjamin Otte — 2009-6-1 @ 9:46 pm

  2. Instead of

    git checkout c186d67f40827be349f97d810a45243c874b73f7
    git bisect good

    you can do

    git bisect good c186d67f40827be349f97d810a45243c874b73f7

    Comment by Adrian Bunk — 2009-6-1 @ 10:02 pm

  3. Yeah, if you can automatically test for the problem, then tools like “bisect run” help a lot for actually tracking down the problem. Of course, once you’ve done so, I hope you’d be adding to a set of automated tests to stop someone from re-introducing the problem in future…

    Comment by Simon — 2009-6-1 @ 11:42 pm

  4. […] every positive experience with git there’s still more than enough negative ones to balance […]

    Pingback by thomas.apestaart.org » git merge conflict — 2009-6-2 @ 11:42 am

  5. If a file changes as part of the standard build process, that file *should not* get checked in.

    Comment by Anonymous — 2009-6-2 @ 5:56 pm

RSS feed for comments on this post. TrackBack URL

Leave a comment

picture