Have you ever hit a regression bug like this: "In chromium 26.0.401.1, things were broken. Back in chromium 126.96.36.199, it was fine."? A good way to attack bugs like this – where it's unclear what change could have caused the regression, but where you have a reliable repro – is to bisect.
tools/bisect-builds.py automates downloading builds of Chrome across a regression range, conducting a binary search for the problematic change. If you don't have a chromium checkout, download
Note: Bisect builds needs Python 2.x. Python 3.x won't work.
Run it like this:
Valid archive types (the -a parameter) are
You can also use the
The script will download a build in the revision range and execute it. You must then manually check if the bug still repros. Quit Chromium, and the script will ask you if the bug reproduced or not. It will use your answer to drive a binary search, and after just a few steps it will tell you "this regression happened somewhere between revisions 1234 and 1334". From that list, it's usually easy to spot the offending CL. If not, you can use the run-bisect-manual-test.py script which will further bisect down to a particular CL by syncing and building manually. If you're adding the range as a comment to a bug, please always paste the output from bisect-builds.py, as this includes links to the chromium and webkit changes in the regression range.
View SVN changes in revision range with this Useful URL (replacing SUCCESS_REV and FAILURE_REV with the range start and end):
If there's a Blink roll in the range, it will all let you know that and recommend you do a Blink bisect (see below.)
Getting an initial revision range
If you have two Chrome binaries, one which doesn't work, one which does, you can check the chrome://version page for the revision that it was built at (look for the "(Official Build NNNNN)" text). You can also infer the revision number from the version number. The third set of numbers in a version number (e.g. the 835 in 14.0.835.202) is the branch number. You can look up http://src.chromium.org/viewvc/chrome/branches/<branch_number>/src/ and see find messages of the form "Branching for <branch_number> @<revision_number>".
Alternatively, you can download an old revision from the continuous build (go to build.chromium.org and then click "continuous" in the upper left corner), verify it doesn't have the problem, and use that.
Use an elevated command prompt for use on Windows
The script currently requires an elevated command prompt to extract the build on Windows.
You can run cmd or cygwin as administrator to work around the silent failure. Track this issue at crbug.com/98739.
You can run the same exact command and pass in the -l option to bisect Blink instead of Chromium. Note that you're still passing the same good and bad Chromium ranges you'd passed in the above Chromium bisect. Nothing changes except that you add a -l option. So the above example would change to:
This will look at Blink's archived builds and should give you a small Blink range.
It should give you the Blink revision range where the regression occurred.
As an example, to isolate the regression range for crbug.com/331899 we used:
This can be annoying, especially if it's a big roll. If that doesn't help, then you can use the run-bisect-manual-test.py script, which will recurse into the Blink, V8 or Skia repositories if you give it a start and end revision range which includes a roll from one of these repositories.
For Developers >