New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 919524 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner: ----
Closed: Jan 8
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 1
Type: Bug



Sign in to add a comment

WebRTC Chromium FYI Mac Builder broken

Project Member Reported by sakal@chromium.org, Jan 7

Issue description

First failure:
https://ci.chromium.org/p/chromium/builders/luci.chromium.webrtc.fyi/WebRTC%20Chromium%20FYI%20Mac%20Builder/1450

For some reason Chromium bot seems fine. Only the WebRTC FYI version is broken. This blocks rolls into WebRTC Chromium.

[36204/36335] LINK ./browser_tests
FAILED: browser_tests 
export DEVELOPER_DIR=/b/s/w/ir/cache/builder/src/build/mac_files/Xcode.app;  TOOL_VERSION=1540406980 ../../build/toolchain/mac/linker_driver.py ../../third_party/llvm-build/Release+Asserts/bin/clang++  -stdlib=libc++ -arch x86_64 -segprot PROTECTED_MEMORY rw r -Werror -Wl,-dead_strip -isysroot ../../build/mac_files/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk -mmacosx-version-min=10.9.0 -Wl,-ObjC -L../../build/mac_files/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/lib -o "./browser_tests" -Wl,-filelist,"./browser_tests.rsp"  -framework Cocoa -framework Foundation -framework IOKit -framework Security -framework SystemConfiguration -framework AppKit -framework ApplicationServices -lbsm -framework CoreFoundation -framework Accelerate -framework AudioUnit -framework DiskArbitration -framework ImageCaptureCore -framework OpenGL -framework QuartzCore -framework SecurityInterface -lcups -framework ServiceManagement -framework Carbon -framework CoreVideo -framework CoreGraphics -framework CoreText -framework IOSurface -framework CFNetwork -framework CoreServices -lresolv -framework IOBluetooth -framework AudioToolbox -framework CoreAudio -framework Quartz -framework AVFoundation -framework CoreMedia -framework VideoToolbox -lsandbox -framework CoreMIDI -framework OpenDirectory -framework LocalAuthentication -framework ForceFeedback -framework GameController -framework CoreWLAN -lbz2
Undefined symbols for architecture x86_64:
  "content::URLLoaderInterceptor::URLLoaderInterceptor(base::RepeatingCallback<bool (content::URLLoaderInterceptor::RequestParams*)> const&)", referenced from:
      extensions::ExtensionUpdateClientBaseTest::SetUpNetworkInterceptors() in extension_update_client_base_browsertest.o
     (maybe you meant: __ZN7content20URLLoaderInterceptorC1ERKN4base17RepeatingCallbackIFbPNS0_13RequestParamsEEEENS1_12OnceCallbackIFvvEEE)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Traceback (most recent call last):
  File "../../build/toolchain/mac/linker_driver.py", line 229, in <module>
    Main(sys.argv)
  File "../../build/toolchain/mac/linker_driver.py", line 79, in Main
    subprocess.check_call(compiler_driver_args)
  File "/b/s/w/ir/cipd_bin_packages/lib/python2.7/subprocess.py", line 186, in check_call
 
Cc: niklase@chromium.org
Components: -Blink>WebRTC
mbonadei@ was trying to find a culprit but locally everything just worked. So it's unlikely to be a WebRTC CL.
And also unlikely to be a Chromium CL because then "chromium.webrtc" waterfall would have started failing as well.
Hm it's actually possible that it's a Chromium CL if the bots (fyi, non-fyi) build different targets. Speculative revert SGTM, that's a nice find.
It looks like it's trying to find the wrong symbol, as the constructor has two parameters now:
content::URLLoaderInterceptor::URLLoaderInterceptor(base::RepeatingCallback<bool (content::URLLoaderInterceptor::RequestParams*)> const&)

I'd like to submit a hopeful fix: https://chromium-review.googlesource.com/c/chromium/src/+/1399043/
(which retains the single-parameter constructor symbol)
, as I'm not sure how to get this bot to test my CL.
Project Member

Comment 7 by bugdroid1@chromium.org, Jan 7

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

commit a11fc96ade7c321ea2dac3bd9331652278e3291a
Author: Dan Harrington <harringtond@chromium.org>
Date: Mon Jan 07 22:15:17 2019

Fix for Mac build

This fix is for what looks like a compiler or linker problem. The previous
code here worked on all other configurations. This change removes a default
parameter in an attempt to fix the link error.

Bug:  919524 
Change-Id: I108c51c361221e4cbda8dda3483883402f34d43a
Reviewed-on: https://chromium-review.googlesource.com/c/1399043
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Commit-Queue: Dan H <harringtond@google.com>
Cr-Commit-Position: refs/heads/master@{#620500}
[modify] https://crrev.com/a11fc96ade7c321ea2dac3bd9331652278e3291a/content/public/test/url_loader_interceptor.cc
[modify] https://crrev.com/a11fc96ade7c321ea2dac3bd9331652278e3291a/content/public/test/url_loader_interceptor.h

Status: Fixed (was: Untriaged)
Now that we've confirmed the 'fix', is there someone responsible for WebRTC who can attempt to track down why this happened? Is there a difference in the compiler/linker/flags?
That would be nice but I don't know where to start from. Consider that it was only failing on 1 FYI bot, everything else was green and I failed to repro on my laptop with the same GN arguments used by the bot.

My guess is that for some reason the object file was not rebuilt after your change and the linker was not able to find the symbol. We were trying to clobber the build before we asked you to fix.
This bot literally just builds Chromium, using Chromium's configs and normal flags.
https://cs.chromium.org/search/?q="WebRTC+Chromium+FYI+Mac+Builder"+-f:json
The difference is in the set of build targets and it also has a slightly fresher WebRTC version.
We just had the exact same situation happen for another unrelated CL. Infra failure followed by consistent compilation failures.

This time we didn't try to submit any fixes but clobbered the cache on the machine, and that helped.

https://ci.chromium.org/p/chromium/builders/luci.chromium.webrtc.fyi/WebRTC%20Chromium%20FYI%20Mac%20Builder?limit=200
Project Member

Comment 13 by bugdroid1@chromium.org, Jan 10

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

commit ac3550ca5437d5b6e7773d6a8617fe0f6283a1e6
Author: Oleh Prypin <oprypin@chromium.org>
Date: Thu Jan 10 20:02:54 2019

Ensure that WebRTC Chromium Mac Builders run on high-performance machines

Because a Mac Mini has been hitting the 2 hour timeout.
https://ci.chromium.org/p/chromium/builders/luci.chromium.webrtc.fyi/WebRTC%20Chromium%20FYI%20Mac%20Builder?limit=200
https://chromium-swarm.appspot.com/botlist?f=os%3AMac&f=pool%3Aluci.chromium.webrtc.fyi

Bug:  919524 
Change-Id: I672a7f42d99e312b1146842386389c15e9776d17
Reviewed-on: https://chromium-review.googlesource.com/c/1404271
Reviewed-by: Stephen Martinis <martiniss@chromium.org>
Commit-Queue: Oleh Prypin <oprypin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#621720}
[modify] https://crrev.com/ac3550ca5437d5b6e7773d6a8617fe0f6283a1e6/infra/config/global/cr-buildbucket.cfg

Sign in to add a comment