For Developers‎ > ‎

Want to bisect your local checkout rather than prebuilt binaries? Use

Have you ever hit a regression bug like this: "In chromium 26.0.401.1, things were broken. Back in chromium, 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/ 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, you can either download here (headversion of 2016/03/15) or fetch it with linux commands below:

curl -s --basic -n "" | base64 -d >

Note: Bisect builds needs Python 2.x. Python 3.x won't work.

Run it like this:

python tools/ -a platform -g good-revision -b bad-revision -- flags-for-chrome

For example,

python tools/ -a mac -g 3894 -b 4000 --use-local-cache -- --no-first-run --user-data-dir=/tmp

Valid archive types (the -a parameter) are mac, win, linux, and linux64.

You can also use the -p option to specify a profile. If no -p or --user-data-dir option is specified, a new profile will be created in a temporary directory each time you are asked to try a build. If you specify a profile folder, point to the directory that's a parent of Default/.

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 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, as this includes links to the chromium changes in the regression range.

View code changes in revision range with this Useful URL (replacing SUCCESS_REV and FAILURE_REV with the range start and end):

Notes: For internal usage, we also enabled bisect builds by commits. Please refer to internal doc for more information.

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<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 and then click "continuous" in the upper left corner), verify it doesn't have the problem, and use that.

Verifying the range

If your revision range is incorrect, or if something about your environment interferes with your reproduction of the bug, you will not get useful results from  If you would prefer to know this as soon as possible, rather than after downloading and checking O(log n) builds, pass the --verify-range option to  This will check the first and last builds in the range before starting the bisect.

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 your shell as administrator to work around the silent failure. Track this issue at

Argh, the offending CL is a  Skia / V8 roll!

This can be annoying, especially if it's a big roll.  If that doesn't help, then you can use the script, which will recurse into the V8 or Skia repositories if you give it a start and end revision range which includes a roll from one of these repositories

If Pepper Flash is required to repro

You will have to locate a Flash binary from an official build. If you suspect a Chromium change causing the regression and the Flash version doesn't matter locate any binary on your machine. For instance:

./ -f /opt/google/chrome/PepperFlash/ -b 232915 -g 230425 -a linux64

python -f "C:\Program Files (x86)\Google\Chrome\Application\31.0.1650.39\PepperFlash\pepflashplayer.dll" -b 232915 -g 230425 -a win

./ -f "/Applications/Google Chrome Framework.framework/Internet Plug-Ins/PepperFlash/PepperFlashPlayer.plugin" -b 232915 -g 230425 -a mac