Issue 813163 is potentially related.

Repros in a local build with

content/shell/tools/breakpad_integration_test.py --verbose --build-dir out/gn --binary out/gn/Content\ Shell.app/Contents/MacOS/Content\ Shell

The isolate off the main waterfall bot works:

python tools/swarming_client/isolateserver.py download -I https://isolateserver.appspot.com --namespace default-gzip -s fdd56a8d9ac3cbc32a380a91d31496d5792b5a29 --target foo2

ontent/shell/tools/breakpad_integration_test.py --verbose --build-dir foo2/out/Release/ --binary foo2/out/Release/Content\ Shell.app/Contents/MacOS/Content\ Shell

Looks like components/crash/content/tools/generate_breakpad_symbols.py doesn't do the right thing for @rpath-build-dirrelative dylibs in component builds.

I think the script mixed up loader_path and executable_path, this makes things go:
diff --git a/components/crash/content/tools/generate_breakpad_symbols.py b/components/crash/content/tools/generate_breakpad_symbols.py
index 24250f81fa1c..3a46b816b9fa 100755
--- a/components/crash/content/tools/generate_breakpad_symbols.py
+++ b/components/crash/content/tools/generate_breakpad_symbols.py
@@ -121,11 +121,11 @@ def GetDeveloperDirMac():
   print 'WARNING: no value found for DEVELOPER_DIR. Some commands may fail.'
 
 
-def GetSharedLibraryDependenciesMac(binary, exe_path):
+def GetSharedLibraryDependenciesMac(binary, loader_path):
   """Return absolute paths to all shared library dependecies of the binary.
 
   This implementation assumes that we're running on a Mac system."""
-  loader_path = os.path.dirname(binary)
+  exe_path = os.path.dirname(binary)
   env = os.environ.copy()
   developer_dir = GetDeveloperDirMac()
   if developer_dir:
@@ -146,16 +146,19 @@ def GetSharedLibraryDependenciesMac(binary, exe_path):
       dep = Resolve(m.group(1), exe_path, loader_path, rpaths)
       if dep:
         deps.append(os.path.normpath(dep))
+      else:
+        print '  warning: failed to resolve %s, exe_path %s, loader_path %s' % (
+            m.group(1), exe_path, loader_path)
   return deps
 
 
-def GetSharedLibraryDependencies(options, binary, exe_path):
+def GetSharedLibraryDependencies(options, binary, loader_path):
   """Return absolute paths to all shared library dependecies of the binary."""
   deps = []
   if sys.platform.startswith('linux'):
     deps = GetSharedLibraryDependenciesLinux(binary)
   elif sys.platform == 'darwin':
-    deps = GetSharedLibraryDependenciesMac(binary, exe_path)
+    deps = GetSharedLibraryDependenciesMac(binary, loader_path)
   else:
     print "Platform not supported."
     sys.exit(1)
@@ -316,9 +319,9 @@ def main():
   # Build the transitive closure of all dependencies.
   binaries = set([options.binary])
   queue = [options.binary]
-  exe_path = os.path.dirname(options.binary)
+  loader_path = os.path.dirname(options.binary)
   while queue:
-    deps = GetSharedLibraryDependencies(options, queue.pop(0), exe_path)
+    deps = GetSharedLibraryDependencies(options, queue.pop(0), loader_path)
     new_deps = set(deps) - binaries
     binaries |= new_deps
     queue.extend(list(new_deps))
diff --git a/content/shell/tools/breakpad_integration_test.py b/content/shell/tools/breakpad_integration_test.py
index cfc41151b4e6..e68f24e6590b 100755

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

commit 8ae7000ffce3f9d9ec34a3279f7f30b3cd69d799
Author: Nico Weber <thakis@chromium.org>
Date: Tue Jun 05 13:15:37 2018

mac: Make content_shell_crash_test work in component builds.

generate_breakpad_symbols.py had exe_path and loader_path swapped, so all
the dylibs that Content Shell Framework.framework depends on in component
builds failed to resolve.

Also make dylib resolve failure a hard error to make diagnosing something like
this harder the next time. (I'll make GetCommandOutput() not silently swallow
errors in a separate CL as well.)

Bug:  849381 
Change-Id: I4bb8a2980f41073939bc30181fd7c7e1c2bbf521
Reviewed-on: https://chromium-review.googlesource.com/1085864
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Commit-Queue: Nico Weber <thakis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#564472}
[modify] https://crrev.com/8ae7000ffce3f9d9ec34a3279f7f30b3cd69d799/components/crash/content/tools/generate_breakpad_symbols.py

The stricter error checking added in the fix for this bug found  issue 850055 .

Manual test:

components/crash/content/tools/generate_breakpad_symbols.py --binary out/gn/Content\ Shell.app/Contents/MacOS/Content\ Shell  --symbols-dir foosym --build-dir out/gn

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

commit 94c597a905a0234a6b04709281919fdee5e07984
Author: Nico Weber <thakis@chromium.org>
Date: Mon Jun 11 20:52:58 2018

Let generate_breakpad_symbols.py use a stack of rpaths on mac.

According to `man dyld`, the rpath search list is a stack of all rpaths
found in all binary images on the path resulting in a load, see comment 14
on  bug 850055 .

Also revert the changes exe_path/loader_path swap from
https://chromium-review.googlesource.com/1085864 , it was incorrect
and is no longer needed after the rpath stack fix.

TEST=both of these commands work:
components/crash/content/tools/generate_breakpad_symbols.py --binary out/gn/Content\ Shell.app/Contents/MacOS/Content\ Shell  --symbols-dir foosym --build-dir out/gn
components/crash/content/tools/generate_breakpad_symbols.py --binary out/gn/Chromium.app/Contents/Versions/69.0.3454.0/Chromium\ Helper.app/Contents/MacOS/Chromium\ Helper  --symbols-dir foosym --build-dir out/gn

Bug:  849381 , 850055 
Change-Id: I28502059f444b5ba523763941b1490c1d2ad5d73
Reviewed-on: https://chromium-review.googlesource.com/1095834
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: Nico Weber <thakis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#566140}
[modify] https://crrev.com/94c597a905a0234a6b04709281919fdee5e07984/components/crash/content/tools/generate_breakpad_symbols.py