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

Issue 661172 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Nov 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 1
Type: Bug



Sign in to add a comment

WebRtcImageCaptureBrowserTest tests very flaky on Marshmallow Tablet Tester

Project Member Reported by aber...@chromium.org, Nov 1 2016

Issue description

WebRtcImageCaptureBrowserTest.GetCapabilities/1, WebRtcImageCaptureBrowserTest.GrabFrame/1, and WebRtcImageCaptureBrowserTest.TakePhoto/1 are very flaky on chromium.android/Marshmallow Tablet Tester; see https://test-results.appspot.com/dashboards/flakiness_dashboard.html#testType=content_browsertests&tests=WebRtcImageCaptureBrowserTest.*

A typical log is https://build.chromium.org/p/chromium.android/builders/Marshmallow%20Tablet%20Tester/builds/6191/steps/content_browsertests/logs/stdio

The failure in this log is:

C 1053.395s Main  [UNKNOWN] WebRtcImageCaptureBrowserTest.GrabFrame/1:
C 1053.395s Main  [ RUN      ] WebRtcImageCaptureBrowserTest.GrabFrame/1
C 1053.395s Main  [WARNING:dns_config_service_posix.cc(316)] Failed to read DnsConfig.
C 1053.395s Main  [ERROR:devtools_http_handler.cc(220)] Cannot start http server for devtools. Stop devtools.
C 1053.395s Main  [WARNING:simple_synchronous_entry.cc(1054)] Could not open platform files for entry.
C 1053.395s Main  
C 1053.395s Main  WebRtcImageCaptureBrowserTest.GrabFrame/1UNKNOWN

This looks similar to bug 661136, but on this bot the flakiness seems to be specific to these tests.

Assigning to mcassas@, who seems to be the owner of these tests.
 
Components: Blink>MediaStream>ImageCapture
Cc: juliatut...@chromium.org
I think the DnsConfig error is a red herring:

1. If we wanted to use the internal DNS resolver (which I don't think we do on Android), we should be able to fail over to platform DNS if we can't read the DNS config.

2. The "cannot start http server" error comes from a failure to open a listening socket, which, given 1, shouldn't break even if for some reason we passed it a hostname to listen on.

Also, bug 661136 shows some test cases passing with these same errors, which suggests they are not fatal, at least in all cases.
Status: Started (was: Assigned)
Oops there was a typo in the CL
https://bugs.chromium.org/p/chromium/issues/detail?id=656810#c5,
let me fix it.
Project Member

Comment 4 by bugdroid1@chromium.org, Nov 2 2016

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

commit 6377f417200f471ee4fdede3d10acf00ecca6d0d
Author: mcasas <mcasas@chromium.org>
Date: Wed Nov 02 19:47:40 2016

Correct typo: Image Capture: enable content_browsertests in Linux/CrOs

ToT reads as if the test-with-fake-device-false is for all platforms
except OS_LINUX, it should be the other way around.

BUG=656810,  661172 

TBR=xianglu@chromium.org since this is a quick trivial fix

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

[modify] https://crrev.com/6377f417200f471ee4fdede3d10acf00ecca6d0d/content/browser/webrtc/webrtc_image_capture_browsertest.cc

Status: Fixed (was: Started)
Fixed (should have never been enabled).
[bulk-edit : please ignore if not applicable]

Could you please set the correct milestone for this issue?

Comment 7 by sshru...@google.com, Nov 23 2016

Components: -Blink>MediaStream>ImageCapture Blink>ImageCapture

Sign in to add a comment