Several VideoFullscreenOrientationLockTests are newly flaky |
|||||||||||||
Issue description"org.chromium.content.browser.VideoFullscreenOrientationLockTest#testEnterExitFullscreenWithAPI" is flaky. This issue was created automatically by the chromium-try-flakes app. Please find the right owner to fix the respective test/step and assign this issue to them. If the step/test is infrastructure-related, please add Infra-Troopers label and change issue status to Untriaged. When done, please remove the issue from Sheriff Bug Queue by removing the Sheriff-Chromium label. We have detected 4 recent flakes. List of all flakes can be found at https://chromium-try-flakes.appspot.com/all_flake_occurrences?key=ahVzfmNocm9taXVtLXRyeS1mbGFrZXNyaQsSBUZsYWtlIl5vcmcuY2hyb21pdW0uY29udGVudC5icm93c2VyLlZpZGVvRnVsbHNjcmVlbk9yaWVudGF0aW9uTG9ja1Rlc3QjdGVzdEVudGVyRXhpdEZ1bGxzY3JlZW5XaXRoQVBJDA. Flaky tests should be disabled within 30 minutes unless culprit CL is found and reverted. Please see more details here: https://sites.google.com/a/chromium.org/dev/developers/tree-sheriffs/sheriffing-bug-queues#triaging-auto-filed-flakiness-bugs
,
Feb 8 2017
Detected 6 new flakes for test/step "org.chromium.content.browser.VideoFullscreenOrientationLockTest#testEnterExitFullscreenWithAPI". To see the actual flakes, please visit https://chromium-try-flakes.appspot.com/all_flake_occurrences?key=ahVzfmNocm9taXVtLXRyeS1mbGFrZXNyaQsSBUZsYWtlIl5vcmcuY2hyb21pdW0uY29udGVudC5icm93c2VyLlZpZGVvRnVsbHNjcmVlbk9yaWVudGF0aW9uTG9ja1Rlc3QjdGVzdEVudGVyRXhpdEZ1bGxzY3JlZW5XaXRoQVBJDA. This message was posted automatically by the chromium-try-flakes app. Since flakiness is ongoing, the issue was moved back into Sheriff Bug Queue (unless already there).
,
Feb 8 2017
Those six have all occurred in the last hour or so. It otherwise had only flaked once since December 20. I suspect something landed today that made this test much more flaky.
,
Feb 8 2017
Using this as the tracking bug for the suite, since several tests in it have seen a surge in flakiness since ~4pm PST today.
,
Feb 8 2017
Issue 689761 has been merged into this issue.
,
Feb 8 2017
Seeing a DCHECK failure in the logcat of failing tests: chromium: [795:795:0208/003759.032818:2173616918:FATAL:begin_frame_source.cc(42)] Check failed: args.sequence_number > last_begin_frame_args_.sequence_number || args.source_id != last_begin_frame_args_.source_id.
,
Feb 8 2017
altimin: https://codereview.chromium.org/2647453003 appears to affect media and scheduling at or below the content layer. Any idea if it could be responsible for a newly flaky DCHECK failure in these tests?
,
Feb 8 2017
Yes, it is likely that this patch is the root cause. I will look into it and most likely revert the patch in several hours.
,
Feb 8 2017
Thanks altimin@, removing from sheriff hot list then.
,
Feb 8 2017
Issue 690002 has been merged into this issue.
,
Feb 8 2017
Mentioned patch was reverted in https://codereview.chromium.org/2688523002/. Let's see if it helps.
,
Feb 8 2017
It's still happening, i.e. see https://build.chromium.org/p/chromium.linux/builders/Android%20Tests%20%28dbg%29/builds/39777 org.chromium.content.browser.VideoFullscreenOrientationLockTest#testEnterExitFullscreenWithAPI
,
Feb 8 2017
,
Feb 8 2017
From the dupe: On https://build.chromium.org/p/tryserver.chromium.android/builders/linux_android_rel_ng?numbuilds=200, 57 of 200 builds saw a content_shell_test_apk failure. I went through the first 10, and in 10/10 cases the failure was due to org.chromium.content.browser.VideoFullscreenOrientationLockTest#testEnterExitFullscreenWithAPI -- so currently over 25% of linux_android_rel_ng runs fail due to this test.
,
Feb 8 2017
From the logcat for https://uberchromegw.corp.google.com/i/chromium.linux/builders/Android%20Tests%20%28dbg%29/builds/39777 Device(0a9c766f43e4b967) 02-08 19:04:50.249 2335 2370 W chromium: [2335:2370:0208/190450.261380:3417746168:WARNING:audio_discard_helper.cc(20)] Input timestamps are not monotonically increasing! ts 0 us diff 0 us Device(0a9c766f43e4b967) 02-08 19:04:50.249 2335 2370 E chromium: [2335:2370:0208/190450.261873:3417746659:ERROR:render_media_log.cc(30)] MediaEvent: MEDIA_ERROR_LOG_ENTRY {"error":"Failed to reconcile encoded audio times with decoded output."} Device(0a9c766f43e4b967) 02-08 19:04:50.249 2335 2370 W chromium: [2335:2370:0208/190450.262373:3417747163:WARNING:audio_discard_helper.cc(20)] Input timestamps are not monotonically increasing! ts 0 us diff 0 us Device(0a9c766f43e4b967) 02-08 19:04:50.269 335 913 D audio_hw_primary: select_devices: out_snd_device(2: speaker) in_snd_device(0: ) Device(0a9c766f43e4b967) 02-08 19:04:50.309 854 906 D dalvikvm: GC_EXPLICIT freed 175K, 21% free 40615K/51076K, paused 3ms+6ms, total 69ms Device(0a9c766f43e4b967) 02-08 19:04:50.419 854 1247 I MediaFocusControl: AudioFocus requestAudioFocus() from android.media.AudioManager@42bf36c8org.chromium.content.browser.AudioFocusDelegate@42c0fbf0 Device(0a9c766f43e4b967) 02-08 19:04:50.459 2270 2274 D dalvikvm: GC_CONCURRENT freed 296K, 3% free 17204K/17592K, paused 3ms+2ms, total 17ms Device(0a9c766f43e4b967) 02-08 19:04:50.589 854 1020 I InputReader: Reconfiguring input devices. changes=0x00000004 Device(0a9c766f43e4b967) 02-08 19:04:50.589 854 1020 I InputReader: Device reconfigured: id=4, name='touch_dev', size 1080x1920, orientation 1, mode 1, display id 0 Device(0a9c766f43e4b967) 02-08 19:04:50.589 854 938 I ActivityManager: Config changes=480 {1.0 ?mcc?mnc en_US ldltr sw360dp w598dp h335dp 480dpi nrml land finger -keyb/v/h -nav/h s.13} Device(0a9c766f43e4b967) 02-08 19:04:50.629 1051 1051 D PhoneStatusBar: mSettingsPanelGravity = 55 Device(0a9c766f43e4b967) 02-08 19:04:50.659 2270 2270 F chromium: [2270:2270:0208/190450.645092:3418129878:FATAL:begin_frame_source.cc(42)] Check failed: args.sequence_number > last_begin_frame_args_.sequence_number || args.source_id != last_begin_frame_args_.source_id.
,
Feb 8 2017
,
Feb 8 2017
staraz@, there are DCHECK failures in begin_frame_source.cc, which cause flakes. https://codereview.chromium.org/2612083002 looks relevant and timelines match. Can you please take a look at this bug?
,
Feb 8 2017
,
Feb 8 2017
Why aren't we reverting if we think this is the culprit? This is negatively affecting the CQ.
,
Feb 8 2017
There is a fix in review now.
,
Feb 8 2017
If this is affecting the CQ (which it is, there are 50 flaky failures in the last day), then we should revert immediately and fix later. I've reverted this now. In the future, please revert first.
,
Feb 8 2017
hmm automatic revert is failing because the patch isn't applying. staraz: can you revert manually?
,
Feb 9 2017
Detected 8 new flakes for test/step "org.chromium.content.browser.VideoFullscreenOrientationLockTest#testEnterExitFullscreenWithAPI". To see the actual flakes, please visit https://chromium-try-flakes.appspot.com/all_flake_occurrences?key=ahVzfmNocm9taXVtLXRyeS1mbGFrZXNyaQsSBUZsYWtlIl5vcmcuY2hyb21pdW0uY29udGVudC5icm93c2VyLlZpZGVvRnVsbHNjcmVlbk9yaWVudGF0aW9uTG9ja1Rlc3QjdGVzdEVudGVyRXhpdEZ1bGxzY3JlZW5XaXRoQVBJDA. This message was posted automatically by the chromium-try-flakes app. Since flakiness is ongoing, the issue was moved back into Sheriff Bug Queue (unless already there).
,
Feb 10 2017
Marking it as available since new flakes were detected after my CL got reverted.
,
Feb 10 2017
The latest of the "new" flakes from 2017-02-09 00:17:44 UTC is at commit position 449100, which was before staraz's patch was reverted (449133).
,
Feb 10 2017
try-flakes still hasn't seen any flakes since the revert landed. Tentatively marking as fixed. Please reopen if try-flakes detects new flakes.
,
Feb 10 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/04c49bf4845979aeff2c740a168de0a936b015af commit 04c49bf4845979aeff2c740a168de0a936b015af Author: staraz <staraz@chromium.org> Date: Fri Feb 10 23:10:31 2017 Move display_ From CompositorFrameSinkSupport To GpuDisplayCompositorFrameSink With FrameGenerator and GpuDisplayCompositorFrameSink having a DisplayPrivate interface, CompositorFrameSinkSupport doesn't need to know about cc::Display. cc::Display::SetLocalSurfaceId() checks and early returns if neither local surface id nor device scale factor has changed. Therefore, FrameGenerator's calling SetLocalSurfaceId() before every SubmitCompositorFrame() doesn't result in extra work. This CL also fixes bug 689869 . The bug was caused by https://codereview.chromium.org/2612083002/. In the previous CL, cc::Display::Initialize() was called inside CompositorFrameSinkSupport(), where CompositorFrameSinkSupport was passed as DisplayClient. CompositorFrameSinkSupport::DisplayOutputSurfaceLost() wasn't doing anything so the CompositorFrameSinkClient didn't get notified when we lost CompositorFrameSink. For bug 676070 , 689916 (flaky tests): The two bugs are caused by CompositorFrameSinkSupport doesn't stop observing BeginFrameSource when it should. By notifying client on output surface lost correctly, DirectCompositorFrameSink detaches from client and destroys CompositorFrameSinkSupport (and hence stop observing BeginFrameSource) at the right time. BUG= 688042 , 689869 , 676070 , 689916 CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel Review-Url: https://codereview.chromium.org/2683583005 Cr-Commit-Position: refs/heads/master@{#449777} [modify] https://crrev.com/04c49bf4845979aeff2c740a168de0a936b015af/cc/ipc/display_compositor.mojom [modify] https://crrev.com/04c49bf4845979aeff2c740a168de0a936b015af/cc/surfaces/compositor_frame_sink_support.cc [modify] https://crrev.com/04c49bf4845979aeff2c740a168de0a936b015af/cc/surfaces/compositor_frame_sink_support.h [modify] https://crrev.com/04c49bf4845979aeff2c740a168de0a936b015af/cc/surfaces/compositor_frame_sink_support_unittest.cc [modify] https://crrev.com/04c49bf4845979aeff2c740a168de0a936b015af/components/display_compositor/gpu_compositor_frame_sink.cc [modify] https://crrev.com/04c49bf4845979aeff2c740a168de0a936b015af/components/display_compositor/gpu_compositor_frame_sink.h [modify] https://crrev.com/04c49bf4845979aeff2c740a168de0a936b015af/components/display_compositor/gpu_display_compositor_frame_sink.cc [modify] https://crrev.com/04c49bf4845979aeff2c740a168de0a936b015af/components/display_compositor/gpu_display_compositor_frame_sink.h [modify] https://crrev.com/04c49bf4845979aeff2c740a168de0a936b015af/components/display_compositor/gpu_offscreen_compositor_frame_sink.cc [modify] https://crrev.com/04c49bf4845979aeff2c740a168de0a936b015af/components/exo/compositor_frame_sink.cc [modify] https://crrev.com/04c49bf4845979aeff2c740a168de0a936b015af/components/exo/surface.cc [modify] https://crrev.com/04c49bf4845979aeff2c740a168de0a936b015af/content/browser/renderer_host/offscreen_canvas_compositor_frame_sink.cc [modify] https://crrev.com/04c49bf4845979aeff2c740a168de0a936b015af/services/ui/ws/frame_generator.cc
,
Feb 10 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/04c49bf4845979aeff2c740a168de0a936b015af commit 04c49bf4845979aeff2c740a168de0a936b015af Author: staraz <staraz@chromium.org> Date: Fri Feb 10 23:10:31 2017 Move display_ From CompositorFrameSinkSupport To GpuDisplayCompositorFrameSink With FrameGenerator and GpuDisplayCompositorFrameSink having a DisplayPrivate interface, CompositorFrameSinkSupport doesn't need to know about cc::Display. cc::Display::SetLocalSurfaceId() checks and early returns if neither local surface id nor device scale factor has changed. Therefore, FrameGenerator's calling SetLocalSurfaceId() before every SubmitCompositorFrame() doesn't result in extra work. This CL also fixes bug 689869 . The bug was caused by https://codereview.chromium.org/2612083002/. In the previous CL, cc::Display::Initialize() was called inside CompositorFrameSinkSupport(), where CompositorFrameSinkSupport was passed as DisplayClient. CompositorFrameSinkSupport::DisplayOutputSurfaceLost() wasn't doing anything so the CompositorFrameSinkClient didn't get notified when we lost CompositorFrameSink. For bug 676070 , 689916 (flaky tests): The two bugs are caused by CompositorFrameSinkSupport doesn't stop observing BeginFrameSource when it should. By notifying client on output surface lost correctly, DirectCompositorFrameSink detaches from client and destroys CompositorFrameSinkSupport (and hence stop observing BeginFrameSource) at the right time. BUG= 688042 , 689869 , 676070 , 689916 CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel Review-Url: https://codereview.chromium.org/2683583005 Cr-Commit-Position: refs/heads/master@{#449777} [modify] https://crrev.com/04c49bf4845979aeff2c740a168de0a936b015af/cc/ipc/display_compositor.mojom [modify] https://crrev.com/04c49bf4845979aeff2c740a168de0a936b015af/cc/surfaces/compositor_frame_sink_support.cc [modify] https://crrev.com/04c49bf4845979aeff2c740a168de0a936b015af/cc/surfaces/compositor_frame_sink_support.h [modify] https://crrev.com/04c49bf4845979aeff2c740a168de0a936b015af/cc/surfaces/compositor_frame_sink_support_unittest.cc [modify] https://crrev.com/04c49bf4845979aeff2c740a168de0a936b015af/components/display_compositor/gpu_compositor_frame_sink.cc [modify] https://crrev.com/04c49bf4845979aeff2c740a168de0a936b015af/components/display_compositor/gpu_compositor_frame_sink.h [modify] https://crrev.com/04c49bf4845979aeff2c740a168de0a936b015af/components/display_compositor/gpu_display_compositor_frame_sink.cc [modify] https://crrev.com/04c49bf4845979aeff2c740a168de0a936b015af/components/display_compositor/gpu_display_compositor_frame_sink.h [modify] https://crrev.com/04c49bf4845979aeff2c740a168de0a936b015af/components/display_compositor/gpu_offscreen_compositor_frame_sink.cc [modify] https://crrev.com/04c49bf4845979aeff2c740a168de0a936b015af/components/exo/compositor_frame_sink.cc [modify] https://crrev.com/04c49bf4845979aeff2c740a168de0a936b015af/components/exo/surface.cc [modify] https://crrev.com/04c49bf4845979aeff2c740a168de0a936b015af/content/browser/renderer_host/offscreen_canvas_compositor_frame_sink.cc [modify] https://crrev.com/04c49bf4845979aeff2c740a168de0a936b015af/services/ui/ws/frame_generator.cc
,
Feb 10 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/04c49bf4845979aeff2c740a168de0a936b015af commit 04c49bf4845979aeff2c740a168de0a936b015af Author: staraz <staraz@chromium.org> Date: Fri Feb 10 23:10:31 2017 Move display_ From CompositorFrameSinkSupport To GpuDisplayCompositorFrameSink With FrameGenerator and GpuDisplayCompositorFrameSink having a DisplayPrivate interface, CompositorFrameSinkSupport doesn't need to know about cc::Display. cc::Display::SetLocalSurfaceId() checks and early returns if neither local surface id nor device scale factor has changed. Therefore, FrameGenerator's calling SetLocalSurfaceId() before every SubmitCompositorFrame() doesn't result in extra work. This CL also fixes bug 689869 . The bug was caused by https://codereview.chromium.org/2612083002/. In the previous CL, cc::Display::Initialize() was called inside CompositorFrameSinkSupport(), where CompositorFrameSinkSupport was passed as DisplayClient. CompositorFrameSinkSupport::DisplayOutputSurfaceLost() wasn't doing anything so the CompositorFrameSinkClient didn't get notified when we lost CompositorFrameSink. For bug 676070 , 689916 (flaky tests): The two bugs are caused by CompositorFrameSinkSupport doesn't stop observing BeginFrameSource when it should. By notifying client on output surface lost correctly, DirectCompositorFrameSink detaches from client and destroys CompositorFrameSinkSupport (and hence stop observing BeginFrameSource) at the right time. BUG= 688042 , 689869 , 676070 , 689916 CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel Review-Url: https://codereview.chromium.org/2683583005 Cr-Commit-Position: refs/heads/master@{#449777} [modify] https://crrev.com/04c49bf4845979aeff2c740a168de0a936b015af/cc/ipc/display_compositor.mojom [modify] https://crrev.com/04c49bf4845979aeff2c740a168de0a936b015af/cc/surfaces/compositor_frame_sink_support.cc [modify] https://crrev.com/04c49bf4845979aeff2c740a168de0a936b015af/cc/surfaces/compositor_frame_sink_support.h [modify] https://crrev.com/04c49bf4845979aeff2c740a168de0a936b015af/cc/surfaces/compositor_frame_sink_support_unittest.cc [modify] https://crrev.com/04c49bf4845979aeff2c740a168de0a936b015af/components/display_compositor/gpu_compositor_frame_sink.cc [modify] https://crrev.com/04c49bf4845979aeff2c740a168de0a936b015af/components/display_compositor/gpu_compositor_frame_sink.h [modify] https://crrev.com/04c49bf4845979aeff2c740a168de0a936b015af/components/display_compositor/gpu_display_compositor_frame_sink.cc [modify] https://crrev.com/04c49bf4845979aeff2c740a168de0a936b015af/components/display_compositor/gpu_display_compositor_frame_sink.h [modify] https://crrev.com/04c49bf4845979aeff2c740a168de0a936b015af/components/display_compositor/gpu_offscreen_compositor_frame_sink.cc [modify] https://crrev.com/04c49bf4845979aeff2c740a168de0a936b015af/components/exo/compositor_frame_sink.cc [modify] https://crrev.com/04c49bf4845979aeff2c740a168de0a936b015af/components/exo/surface.cc [modify] https://crrev.com/04c49bf4845979aeff2c740a168de0a936b015af/content/browser/renderer_host/offscreen_canvas_compositor_frame_sink.cc [modify] https://crrev.com/04c49bf4845979aeff2c740a168de0a936b015af/services/ui/ws/frame_generator.cc |
|||||||||||||
►
Sign in to add a comment |
|||||||||||||
Comment 1 by jbudorick@chromium.org
, Dec 20 2016Labels: -Sheriff-Chromium
Owner: jbudorick@chromium.org
Status: Assigned (was: Untriaged)