I see the same thing.  Also note that if you hit (s) to see the stdout, it shows the following error:

dlopen /private/var/folders/bq/sz4kfvl55ng0zdhwdyywvyxw001rk1/T/bisect_tmpZjZFpr/chrome-mac/Chromium.app/Contents/MacOS/../Versions/59.0.3034.0/Chromium Framework.framework/Chromium Framework: dlopen(/private/var/folders/bq/sz4kfvl55ng0zdhwdyywvyxw001rk1/T/bisect_tmpZjZFpr/chrome-mac/Chromium.app/Contents/MacOS/../Versions/59.0.3034.0/Chromium Framework.framework/Chromium Framework, 261): no suitable image found.  Did find:
	/private/var/folders/bq/sz4kfvl55ng0zdhwdyywvyxw001rk1/T/bisect_tmpZjZFpr/chrome-mac/Chromium.app/Contents/MacOS/../Versions/59.0.3034.0/Chromium Framework.framework/Chromium Framework: file too short

The file it mentions doesn't exist by the time the prompt appears (possibly the bisect script cleans up the temp dir immediately).

If bisect script doesn't launch Chrome because 'trustworthiness cannot be determined'. In that case you need to request an exception from Tech stop on Santa operating mode.

Please follow instructions in https://support.google.com/techstop/answer/2690761

More Info on script usage- https://sites.google.com/a/google.com/chrome-te/home/tools/bisect-builds

Please feel free to update the thread with your findings.

I have an exception for my machine already - go/upvote/hosts reports "Status: Minimally Protected (Host Exception)".  I am also able to run local trunk builds without issue.

Let me give a try on my local machine.

I am seeing the similar issue from my end as well.

I also have an exception for my machine. 

Also, it turned out that the problem might be on the end of build uploader; bisect-builds.py successfully bisects some old ranges (e.g. python tools/bisect-builds.py -a mac -g 354298 -b 355669 --use-local-cache)

Assigning to Prasad for further investigation.

This seems to be specific to 'Mac OS X' only. The below regression range working fine for 'Windows' without any issues.
python bisect-builds.py -o -g 59.0.3033.0 -b 59.0.3034.0 -a win64

Thank you!

Did a quick check and noticing the chromium revisions >= r451180 (M58 & 3015 branch) are NOT getting invoked through the public/internal bisect script.

PS: All chromium revisions belongs to branch:3014 (base revision: r450840) are getting invoked without any issues.

Thank you!

I'm suspecting https://crrev.com/451175 for bisect-builds.py fails to launch Chrome on Mac OS. Script fail to launch Chrome on any build for the revisions landed after this.

rsesek@, bisect-builds.py uses lightweight Chrome archives in order to launch Chrome on Mac and other OS.
On Mac Chrome build archives consist of Google Chrome.app and gen folder.

But for the Chrome revisions >=r451175 we are seeing following error on launching chrome:

dlopen /private/var/folders/00/0cfzh000h01000cxqpysvccm001jvy/T/bisect_tmpk9FzAm/full-build-mac_451177/Google Chrome.app/Contents/MacOS/../Versions/58.0.3015.0/Google Chrome Framework.framework/Google Chrome Framework: dlopen(/private/var/folders/00/0cfzh000h01000cxqpysvccm001jvy/T/bisect_tmpk9FzAm/full-build-mac_451177/Google Chrome.app/Contents/MacOS/../Versions/58.0.3015.0/Google Chrome Framework.framework/Google Chrome Framework, 261): no suitable image found.  Did find:

/private/var/folders/00/0cfzh000h01000cxqpysvccm001jvy/T/bisect_tmpk9FzAm/full-build-mac_451177/Google Chrome.app/Contents/MacOS/../Versions/58.0.3015.0/Google Chrome Framework.framework/Google Chrome Framework: file too short

Can you please take a look at this and let us know if anything has be done from our end.


Here is a link to the buildbot archives binaries on Mac for the purpose of bisection:
https://luci-logdog.appspot.com/v/?s=chrome%2Fbb%2Fchromium.perf%2FMac_Builder%2F77088%2F%2B%2Frecipes%2Fsteps%2Fpackage_build_for_bisect%2F0%2Fstdout

The problem is that bisect-builds.py uses Python's zipfile module to unzip the contents: https://cs.chromium.org/chromium/src/tools/bisect-builds.py?q=bisect-builds.py&sq=package:chromium&dr=C&l=455

The zip files now include symbolic links, which are not properly handled by Python's zipfile implementation. Instead, you will need to use the `unzip` command on Mac.

So for the Per CL bisect, we only archive Google Chrome.app and gen folder. Are there any other folders that we should archive along with them.
Because when I manually extract these zips and launch I get the same error.

My bad, using unzip command manually did work! I'll make the changes to script and upload the patch.
Thank you Robert!

This is fixed now for the internal version of bisect-builds.py
https://chrome-internal.googlesource.com/chrome/test/python_tests/+/master/bisect-builds.py

Thank you Prasad for the fix.. 

Tried new script for couple of different ranges and it is working fine (Chrome Invoked)
eg:
python bisect-builds.py -a mac -g 354298 -b 355669
python bisect-builds.py -o -a mac -g 455955 -b 456244
python bisect-builds.py -o -a mac -g 455955 -b 456295
python bisect-builds.py -o -a mac -g 59.0.3033.0 -b 59.0.3034.0

Can the fix be applied to the external version?

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/2375e6dc4842a87abb21b9f1908fdcd3966ae54c

commit 2375e6dc4842a87abb21b9f1908fdcd3966ae54c
Author: prasadv <prasadv@google.com>
Date: Mon Mar 20 19:23:23 2017

Use system command to unzip binaries from zip file on Mac OS
BUG= 700097 

Review-Url: https://codereview.chromium.org/2757333002
Cr-Commit-Position: refs/heads/master@{#458149}

[modify] https://crrev.com/2375e6dc4842a87abb21b9f1908fdcd3966ae54c/tools/bisect-builds.py

Added the fix to external version of bisect-builds.py.

Thank you :)