this seems weird. I presume that you are doing a CrOS build? It seems that gclient is not freshening the third_party correctly?

I am building CrOS locally, do you have a suggestion for diagnosing possible gclient/third_party defects?

I have this vague recollection that there was an depot_tools change shortly after the last branch that made building older checkouts difficult. Might be worth someone on infra?

I don't think my local builds are that closely related to the pre-built binaries pulled down by bisect-builds.py, I'm also not targeting anything that old; my ToT is at #501046, and I'm trying builds less than a hundred revisions prior.

#3, do older builds require older checkout? (this is binary bisect, just in case you might have missed)

I got it to work with these hacks:

* At the "is this revision good" prompt, use another shell to look for the <rev>-chrome-linux.zip files. Unzip manually, which creates dir "chrome-linux"
* Copy out/Debug/libminigbm.so file into chrome-linux
* Run chrome from command line

So maybe whatever creates the .zip files just needs to copy libminigbm.so into the archive?

dpranke, do you know what makes those zip files?

Prasad, can you look into whether we need to add something to the archives here?

Ping! This is rather annoying and makes it difficult to bisect builds. I'm guessing that delays fixing this will cause this issue to persist in perpetuity when bisecting around the affected build range...

Also, for working around this issue, is there a directory that the bisect tool extracts to that I can re-use while bisecting, or do i need to separately extract the zip files myself?

I'm really sorry that this issue is blocking you from bisecting.
Mostly I deal with with Desktop and Android bisects, honestly I never worked on chromeOS bisects.
But I tried to investigate this further, basically for ChromeOS, bisect-builds.py pulls the builds from http://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?prefix=Linux_ChromiumOS_Full/ <revision>.
These builds are archived and uploaded here by builder
https://build.chromium.org/p/chromium.chromiumos/waterfall?show=Linux%20ChromiumOS%20Full

I noticed that the file libminigbm.so is not at all archived into the chrome_linux.zip and I don't see this in the build artifacts on the builder.
Unless we modify the builder to archive missing files, bisect will fail for chromeOS.


For you question on 
"for working around this issue, is there a directory that the bisect tool extracts to that I can re-use while bisecting"
While bisecting, the script extracts the archive in /tmp/bisect_tmp<tempory-name>/chrome-linux/
(Here is the relevant codes; https://cs.chromium.org/chromium/src/tools/bisect-builds.py?l=540)

So. I think this worked for a while, but is now broken for a new reason. That is, since ~January, 2018, all renderers immediately crash. I think due to r531204. You do get a usable shelf/tray though :/

There is also Issue 663450, which is the python_tests' version of the bisect script (which fares worse). But comments above are about the script in the chromium repo. Which I think is broken for different reasons, hence closing this bug.

Feel free to reopen, or merge into Issue 663450, or just star https://crbug.com/663450 . I'll ping this bug when I've filed a new bug for the crashing renderers.