It looks like this failure was introduced in:

https://uberchromegw.corp.google.com/i/official.desktop.continuous/builders/linux64%20trunk/builds/13443

(along with new browser_tests failures -- is there a bug for those too?)

Perhaps related to:
https://webrtc.googlesource.com/src.git/+/dd20c9c1e3f681f6c33d1879c76f588bd4b095bd

which was brought in by the roll in:
https://chromium.googlesource.com/chromium/src/+/338e2095e09bbfa5071553b0b3f836c1f520a7aa


This one, which also involves some media/capture stuff, might also be related (or perhaps related to the other browser_tests failures):
https://chromium.googlesource.com/chromium/src/+/f349e11b1f75b9de167123d83718b3bd7b0aee6e

Just to update:

Same issue seen in official and continuous builder builds--

Link to the builder:
---------------------
https://uberchromegw.corp.google.com/i/official.desktop.continuous/builders/linux64%20trunk/builds/13533
https://uberchromegw.corp.google.com/i/official.desktop/builders/linux64/builds/2009

Thanks!

Sorry, didn't see this until now. All right, I'll revert the patch in #3 for now. Interesting it's not crashing on regular Linux bots.

The revert is going in now, and then it will take a few hours at best for it to roll into Chromium.

The following revision refers to this bug:
  https://webrtc.googlesource.com/src.git/+/3ddaf3c40881ad98c480f0df7cfec6d50d4cdca5

commit 3ddaf3c40881ad98c480f0df7cfec6d50d4cdca5
Author: Patrik Höglund <phoglund@webrtc.org>
Date: Tue Nov 06 14:17:34 2018

Revert "Add support for screen sharing with PipeWire on Wayland"

This reverts commit dd20c9c1e3f681f6c33d1879c76f588bd4b095bd.

Reason for revert: Speculative revert; looks like it causes crashes on official builders. See  crbug.com/901319 .

Original change's description:
> Add support for screen sharing with PipeWire on Wayland
>
> Currently, when users want to use the screen sharing and are using the
> Wayland display server (the default on Fedora distribution), then it
> doesn't work, because the WebRTC only includes the X11 implementation.
> This change adds the support by using the PipeWire multimedia server.
>
> The PipeWire implementation in WebRTC stays in
> screen-capturer-pipewire.c and is guarded by the rtc_use_pipewire build
> flag that is automatically enabled on Linux.
>
> More information are included in the relevant commit messages.
>
> Tested on the current Chromium master and Firefox.
>
> The sysroot changes are requested in:
> https://chromium-review.googlesource.com/c/chromium/src/+/1258174
>
> Co-authored-by: Jan Grulich <grulja@gmail.com>
> Co-authored-by: Eike Rathke <erathke@redhat.com>
> Change-Id: I212074a4bc437b99a77bf383266026c5bfae7c4a
>
> BUG=chromium:682122
>
> Change-Id: I212074a4bc437b99a77bf383266026c5bfae7c4a
> Reviewed-on: https://webrtc-review.googlesource.com/c/103504
> Commit-Queue: Patrik Höglund <phoglund@webrtc.org>
> Reviewed-by: Patrik Höglund <phoglund@webrtc.org>
> Reviewed-by: Brave Yao <braveyao@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#25461}

TBR=phoglund@webrtc.org,jamiewalch@chromium.org,niklas.enbom@webrtc.org,braveyao@webrtc.org,tomas.popela@gmail.com

# Not skipping CQ checks because original CL landed > 1 day ago.

NOPRESUBMIT=true

Bug: chromium:682122,  chromium:901319 
Change-Id: I4ca5da77daea73cae1232953a0d633900a85a93d
Reviewed-on: https://webrtc-review.googlesource.com/c/109584
Commit-Queue: Patrik Höglund <phoglund@webrtc.org>
Reviewed-by: Patrik Höglund <phoglund@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25522}
[modify] https://crrev.com/3ddaf3c40881ad98c480f0df7cfec6d50d4cdca5/AUTHORS
[modify] https://crrev.com/3ddaf3c40881ad98c480f0df7cfec6d50d4cdca5/modules/desktop_capture/BUILD.gn
[modify] https://crrev.com/3ddaf3c40881ad98c480f0df7cfec6d50d4cdca5/modules/desktop_capture/desktop_capture_options.h
[modify] https://crrev.com/3ddaf3c40881ad98c480f0df7cfec6d50d4cdca5/modules/desktop_capture/desktop_capturer.cc
[modify] https://crrev.com/3ddaf3c40881ad98c480f0df7cfec6d50d4cdca5/modules/desktop_capture/desktop_capturer.h
[delete] https://crrev.com/82c07ea1da4ac4a0df469333fe2142da27b6de21/modules/desktop_capture/linux/base_capturer_pipewire.cc
[delete] https://crrev.com/82c07ea1da4ac4a0df469333fe2142da27b6de21/modules/desktop_capture/linux/base_capturer_pipewire.h
[delete] https://crrev.com/82c07ea1da4ac4a0df469333fe2142da27b6de21/modules/desktop_capture/linux/mouse_cursor_monitor_x11.h
[delete] https://crrev.com/82c07ea1da4ac4a0df469333fe2142da27b6de21/modules/desktop_capture/linux/screen_capturer_pipewire.cc
[delete] https://crrev.com/82c07ea1da4ac4a0df469333fe2142da27b6de21/modules/desktop_capture/linux/screen_capturer_pipewire.h
[delete] https://crrev.com/82c07ea1da4ac4a0df469333fe2142da27b6de21/modules/desktop_capture/linux/screen_capturer_x11.h
[delete] https://crrev.com/82c07ea1da4ac4a0df469333fe2142da27b6de21/modules/desktop_capture/linux/window_capturer_pipewire.cc
[delete] https://crrev.com/82c07ea1da4ac4a0df469333fe2142da27b6de21/modules/desktop_capture/linux/window_capturer_pipewire.h
[delete] https://crrev.com/82c07ea1da4ac4a0df469333fe2142da27b6de21/modules/desktop_capture/linux/window_capturer_x11.h
[delete] https://crrev.com/82c07ea1da4ac4a0df469333fe2142da27b6de21/modules/desktop_capture/mouse_cursor_monitor_linux.cc
[rename] https://crrev.com/3ddaf3c40881ad98c480f0df7cfec6d50d4cdca5/modules/desktop_capture/mouse_cursor_monitor_x11.cc
[delete] https://crrev.com/82c07ea1da4ac4a0df469333fe2142da27b6de21/modules/desktop_capture/screen_capturer_linux.cc
[rename] https://crrev.com/3ddaf3c40881ad98c480f0df7cfec6d50d4cdca5/modules/desktop_capture/screen_capturer_x11.cc
[modify] https://crrev.com/3ddaf3c40881ad98c480f0df7cfec6d50d4cdca5/modules/desktop_capture/screen_drawer_linux.cc
[delete] https://crrev.com/82c07ea1da4ac4a0df469333fe2142da27b6de21/modules/desktop_capture/window_capturer_linux.cc
[rename] https://crrev.com/3ddaf3c40881ad98c480f0df7cfec6d50d4cdca5/modules/desktop_capture/window_capturer_x11.cc
[modify] https://crrev.com/3ddaf3c40881ad98c480f0df7cfec6d50d4cdca5/modules/desktop_capture/window_finder_unittest.cc
[rename] https://crrev.com/3ddaf3c40881ad98c480f0df7cfec6d50d4cdca5/modules/desktop_capture/window_finder_x11.cc
[rename] https://crrev.com/3ddaf3c40881ad98c480f0df7cfec6d50d4cdca5/modules/desktop_capture/window_finder_x11.h
[rename] https://crrev.com/3ddaf3c40881ad98c480f0df7cfec6d50d4cdca5/modules/desktop_capture/x11/shared_x_display.cc
[rename] https://crrev.com/3ddaf3c40881ad98c480f0df7cfec6d50d4cdca5/modules/desktop_capture/x11/shared_x_display.h
[rename] https://crrev.com/3ddaf3c40881ad98c480f0df7cfec6d50d4cdca5/modules/desktop_capture/x11/window_list_utils.cc
[rename] https://crrev.com/3ddaf3c40881ad98c480f0df7cfec6d50d4cdca5/modules/desktop_capture/x11/window_list_utils.h
[rename] https://crrev.com/3ddaf3c40881ad98c480f0df7cfec6d50d4cdca5/modules/desktop_capture/x11/x_atom_cache.cc
[rename] https://crrev.com/3ddaf3c40881ad98c480f0df7cfec6d50d4cdca5/modules/desktop_capture/x11/x_atom_cache.h
[rename] https://crrev.com/3ddaf3c40881ad98c480f0df7cfec6d50d4cdca5/modules/desktop_capture/x11/x_error_trap.cc
[rename] https://crrev.com/3ddaf3c40881ad98c480f0df7cfec6d50d4cdca5/modules/desktop_capture/x11/x_error_trap.h
[rename] https://crrev.com/3ddaf3c40881ad98c480f0df7cfec6d50d4cdca5/modules/desktop_capture/x11/x_server_pixel_buffer.cc
[rename] https://crrev.com/3ddaf3c40881ad98c480f0df7cfec6d50d4cdca5/modules/desktop_capture/x11/x_server_pixel_buffer.h
[modify] https://crrev.com/3ddaf3c40881ad98c480f0df7cfec6d50d4cdca5/webrtc.gni

Would it be possible to get more info about it? It passes for me locally:

0 $ ./content_unittests --gtest_filter=DesktopCaptureDeviceTest.Capture
IMPORTANT DEBUGGING NOTE: batches of tests are run inside their
own process. For debugging a test inside a debugger, use the
--gtest_filter=<your_test_name> flag along with
--single-process-tests.
Using sharding settings from environment. This is shard 0/1
Using 1 parallel jobs.
Note: Google Test filter = DesktopCaptureDeviceTest.Capture
[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from DesktopCaptureDeviceTest
[ RUN      ] DesktopCaptureDeviceTest.Capture
[       OK ] DesktopCaptureDeviceTest.Capture (38 ms)
[----------] 1 test from DesktopCaptureDeviceTest (55 ms total)

[----------] Global test environment tear-down
[==========] 1 test from 1 test case ran. (55 ms total)
[  PASSED  ] 1 test.
[1/1] DesktopCaptureDeviceTest.Capture (38 ms)
SUCCESS: all tests passed.
Tests took 0 seconds.

I'm curious why this is actually causing any failure as the change is disabled in compilation time (unless explicitly enabled) and disabled in the runtime through DesktopCaptureOptions.

Yeah, in that case it must be something like that parts of your feature are accidentally enabled even if the GN flag is off.

The gn flags used by the builder is

is_chrome_branded = true
is_debug = false
is_official_build = true 

so try with those.

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

commit a9e4ec1adb5906b7186faeec89f4ddf82950ad16
Author: chromium-autoroll <chromium-autoroll@skia-public.iam.gserviceaccount.com>
Date: Tue Nov 06 18:16:16 2018

Roll src/third_party/webrtc a8f54617c08d..277b6ea8508e (4 commits)

https://webrtc.googlesource.com/src.git/+log/a8f54617c08d..277b6ea8508e


git log a8f54617c08d..277b6ea8508e --date=short --no-merges --format='%ad %ae %s'
2018-11-06 alessiob@webrtc.org Isolating APM API build target: adding dummy :api target.
2018-11-06 phoglund@webrtc.org Revert "Add support for screen sharing with PipeWire on Wayland"
2018-11-06 ilnik@webrtc.org Tune huge video frames detection threshold for GetStats googHugeFramesSent stat
2018-11-06 sprang@webrtc.org Make VideoSendStreamTest.NoPaddingWhenVideoIsMuted less flaky


Created with:
  gclient setdep -r src/third_party/webrtc@277b6ea8508e

The AutoRoll server is located here: https://autoroll.skia.org/r/webrtc-chromium-autoroll

Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md

If the roll is causing failures, please contact the current sheriff, who should
be CC'd on the roll, and stop the roller if necessary.

CQ_INCLUDE_TRYBOTS=luci.chromium.try:linux_chromium_archive_rel_ng;luci.chromium.try:mac_chromium_archive_rel_ng

BUG=chromium:682122, chromium:901319 ,chromium:none
TBR=webrtc-chromium-sheriffs-robots@google.com

Change-Id: I6dadb5c6014d55b6065ea8c415045b3854688c65
Reviewed-on: https://chromium-review.googlesource.com/c/1319810
Reviewed-by: chromium-autoroll <chromium-autoroll@skia-public.iam.gserviceaccount.com>
Commit-Queue: chromium-autoroll <chromium-autoroll@skia-public.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#605743}
[modify] https://crrev.com/a9e4ec1adb5906b7186faeec89f4ddf82950ad16/DEPS

Looks like the revert fixed all the failing tests (including some that I wasn't sure were related, like FeedbackTest):

https://uberchromegw.corp.google.com/i/official.desktop.continuous/builders/linux64%20trunk/builds/13546

Ok, that's good!

Tomas: Yeah, I wonder why you can't repro. It looks like the tests passed content_unittests on the roll CL https://chromium-review.googlesource.com/c/chromium/src/+/1312640: see https://chromium-swarm.appspot.com/task?id=40e7e2f60bc4d910&refresh=10&show_raw=1. The Capture test just passes.

That it fails on the official bot only could hint that

is_chrome_branded = true
is_debug = false
is_official_build = true

is the reason why this happens. I know they have an effect on which codecs are available to WebRTC, but i'm not sure how that relates to your CL. I hope you can set those even though you're not a googler (not sure).

Other hints is this comment on the Capture test in desktop_capture_device_unittest.cc:

// There is currently no screen capturer implementation for ozone. So disable
// the test that uses a real screen-capturer instead of FakeScreenCapturer.
//  http://crbug.com/260318 

Looks like it uses a "real" screen capturer, whatever that means.

Compiling it right now (but it will take some time as I can't compile with icecc and the is_official_build enabled at the same time).

But when I see that comment regarding to the Capture test, we should probably disable it for PipeWire as well because the PipeWire implementation uses xdg-desktop-portal and it spawns confirmation dialog so I don't expect that it will work in unit tests.

Found the problem:

../../third_party/webrtc/modules/desktop_capture/linux/x_server_pixel_buffer.cc:147:5: runtime error: control flow integrity check for type 'int (_XImage *)' failed during indirect function call

scratched my head for quite some time (trying to fix it), but then I looked at //tools/cfi/blacklist.txt and what I found there:

src:*third_party/webrtc/modules/desktop_capture/x11/x_server_pixel_buffer.cc

but as that filed was moved to

//third_party/webrtc/modules/desktop_capture/linux/x_server_pixel_buffer.cc

the blacklist doesn't apply.

I will create a new change for adding the new path to the blacklist, when it lands, someone could roll that WebRTC change (or revert that Chromium revert) and when that is finished, then we can remove the original path from the blacklist.

Nice find!

Just to update we are seeing HangoutServicesBrowserTest.RunComponentExtensionTest failure on the latest ToT on Linux(72.0.3605.0) which looks to be rooted to this and Issue 902278.

Link to the builder:
====================
https://goto.google.com/xeukk

Link to the log:
================
https://goto.google.com/cuyuw

Error log:
===========
Stack trace:
#0 0x7f53a123a0af (/b/c/b/linux64/src/out/Release/browser_tests+0x64300ae)

[34848:34848:1108/005432.727206:WARNING:pref_notifier_impl.cc(23)] Pref observer found at shutdown.
[34848:34848:1108/005432.734045:WARNING:pref_notifier_impl.cc(23)] Pref observer found at shutdown.
[  FAILED  ] HangoutServicesBrowserTest.RunComponentExtensionTest, where TypeParam =  and GetParam() =  (9966 ms)
[10208/10208] HangoutServicesBrowserTest.RunComponentExtensionTest (10222 ms)
1 test failed:
    HangoutServicesBrowserTest.RunComponentExtensionTest (../../chrome/browser/extensions/api/webrtc_audio_private/webrtc_audio_private_browsertest.cc:255)
<Thread(Thread-1, started 139874088908544)> ProcessRead: proc.stdout finished.
<Thread(Thread-1, started 139874088908544)> ProcessRead: cleaning up.
<Thread(Thread-2, started daemon 139874080515840)> TimedFlush: Finished
<Thread(Thread-1, started 139874088908544)> ProcessRead: finished.
Stopping Xvfb with pid 20474 ...
Xvfb pid file removed

@ajha it would be nice if you are able to retry it with https://chromium-review.googlesource.com/c/chromium/src/+/1325801 applied. I can compile it myself, but it will take few hours. 

I don't think #16 is related. It also failed on the continuous builders, starting after these changes:
https://uberchromegw.corp.google.com/i/official.desktop.continuous/builders/linux64%20trunk/builds/13580

and is now passing again in the most recent build:
https://uberchromegw.corp.google.com/i/official.desktop.continuous/builders/linux64%20trunk/builds/13583

Actually, it looks like that HangoutServicesBrowserTest is just something flaky. Going back farther in the continuous builds, I see it flip-flopping between pass and fail quite a bit, with no obvious cause, but still unlikely related to these changes.

Patrik or anyone, how the workflow will look like for bringing back the reverted change to WebRTC? Is it possible to commit it again from the original gerrit change or I have to do another one?

Re #20: You're not a committer so you can't use the reland button I think. Do this:

$ git checkout master
$ git pull origin master
$ git checkout -b reland
$ git revert 3ddaf3c40881ad98c480f0df7cfec6d50d4cdca5
$ git cl upload
Do any required fixes and commit locally
$ git cl upload
Get review

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

commit 33ae9b1b503ee3dfb711c36bc13aa76456175bed
Author: Tomas Popela <tomas.popela@gmail.com>
Date: Mon Nov 12 22:24:18 2018

Specify both paths for x_server_pixel_buffer.cc in cfi blacklist

This is needed because the WebRTC change is moving the files and the
lack of the new entry in the blacklist will cause a crash in
content_unittests's DesktopCaptureDeviceTest.Capture. See
https://bugs.chromium.org/p/chromium/issues/detail?id=901319#c14.

Bug:  901319 
Change-Id: I547c663c42a315841415032a6d53141a051ad402
Reviewed-on: https://chromium-review.googlesource.com/c/1325801
Reviewed-by: Patrik Höglund <phoglund@chromium.org>
Reviewed-by: Michael Moss <mmoss@chromium.org>
Reviewed-by: Peter Collingbourne <pcc@chromium.org>
Commit-Queue: Tomáš Popela <tomas.popela@gmail.com>
Cr-Commit-Position: refs/heads/master@{#607353}
[modify] https://crrev.com/33ae9b1b503ee3dfb711c36bc13aa76456175bed/tools/cfi/blacklist.txt