"org.chromium.chrome.browser.profiling_host.ProfilingProcessHostAndroidTest#testModeRendererPseudo" is flaky |
|||||||
Issue description"org.chromium.chrome.browser.profiling_host.ProfilingProcessHostAndroidTest#testModeRendererPseudo" 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 3 recent flakes. List of all flakes can be found at https://chromium-try-flakes.appspot.com/all_flake_occurrences?key=ahVzfmNocm9taXVtLXRyeS1mbGFrZXNybAsSBUZsYWtlImFvcmcuY2hyb21pdW0uY2hyb21lLmJyb3dzZXIucHJvZmlsaW5nX2hvc3QuUHJvZmlsaW5nUHJvY2Vzc0hvc3RBbmRyb2lkVGVzdCN0ZXN0TW9kZVJlbmRlcmVyUHNldWRvDA. 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 This flaky test/step was previously tracked in issue 803568 .
,
Jan 22 2018
Interesting. The flakiness has changed after https://chromium-review.googlesource.com/c/chromium/src/+/876304. Now, the tests are timing out. This almost certainly happens in WaitForProfilingToStartForAllRenderersUIThreadAndSignal. This happens when the renderer process starts before OOP HP is started, even though the flags are passed as a command line flag, which is as early as we can get it. I guess this is because Android has a different scheme for starting renderers which doesn't go through the normal pathway (?). Will need to think about this. +maria in case she has any more insight.
,
Jan 23 2018
Sheriff: disabling this test as <https://chromium-review.googlesource.com/#/c/chromium/src/+/881202>.
,
Jan 23 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/81aea7c6740d5f653cdb61b79ff7a4fc7460cf56 commit 81aea7c6740d5f653cdb61b79ff7a4fc7460cf56 Author: Elly Fong-Jones <ellyjones@chromium.org> Date: Tue Jan 23 15:08:07 2018 sheriff: disable testModeRendererPseudo on Android TBR=mariakhomenko@chromium.org Bug: 804412 Change-Id: Ie219e2e64f4864fe5ad3ed43681b3252565ac453 Reviewed-on: https://chromium-review.googlesource.com/881202 Commit-Queue: Elly Fong-Jones <ellyjones@chromium.org> Reviewed-by: Elly Fong-Jones <ellyjones@chromium.org> Cr-Commit-Position: refs/heads/master@{#531238} [modify] https://crrev.com/81aea7c6740d5f653cdb61b79ff7a4fc7460cf56/chrome/android/javatests/src/org/chromium/chrome/browser/profiling_host/ProfilingProcessHostAndroidTest.java
,
Jan 23 2018
Untagging sheriffs since this test is now disabled.
,
Jan 23 2018
Hmm, could this have to do with the warm-up renderer we create first thing on startup? https://cs.chromium.org/chromium/src/content/public/android/java/src/org/chromium/content/browser/ChildProcessLauncherHelper.java?rcl=d42fb1e483509b1a34a851b53b3a950c55d58cfa&l=224 and https://cs.chromium.org/chromium/src/chrome/android/java/src/org/chromium/chrome/browser/init/AsyncInitTaskRunner.java?rcl=d42fb1e483509b1a34a851b53b3a950c55d58cfa&l=159 That renderer is then used for the next navigation that comes along.
,
Jan 23 2018
Detected 3 new flakes for test/step "org.chromium.chrome.browser.profiling_host.ProfilingProcessHostAndroidTest#testModeRendererPseudo". To see the actual flakes, please visit https://chromium-try-flakes.appspot.com/all_flake_occurrences?key=ahVzfmNocm9taXVtLXRyeS1mbGFrZXNybAsSBUZsYWtlImFvcmcuY2hyb21pdW0uY2hyb21lLmJyb3dzZXIucHJvZmlsaW5nX2hvc3QuUHJvZmlsaW5nUHJvY2Vzc0hvc3RBbmRyb2lkVGVzdCN0ZXN0TW9kZVJlbmRlcmVyUHNldWRvDA. 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).
,
Jan 23 2018
Test was disabled but sheriff tag was re-added from a previous flake run. Removing tag since this *should* not be running any longer.
,
Jan 26 2018
Thanks Maria. That sounds like a likely explanation. I'll add a workaround and re-enable the test.
,
Jan 29 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/4c353749ab3fb37cc4b8dd0f6693db4328c54ee5 commit 4c353749ab3fb37cc4b8dd0f6693db4328c54ee5 Author: erikchen <erikchen@chromium.org> Date: Mon Jan 29 19:34:36 2018 Fix flakiness in Android renderer OOPHP test. The current flakiness occurs in the form of a timeout waiting for profiling to start for renderers. On Android, there's a warm-up renderer that could start before ProfilingProcessHost gets a chance to start up - as such, it will never be profiled. This CL adds logic to force profiling to start for all renderers, which should fix the flakiness. This CL also fixes a bug in ProfilingClient, which was only keeping the most recent binding. Bug: 804412 Change-Id: I836e55650b30a6360e0bc0f9189aacb7a75ea0c9 Reviewed-on: https://chromium-review.googlesource.com/889999 Reviewed-by: Maria Khomenko <mariakhomenko@chromium.org> Commit-Queue: Erik Chen <erikchen@chromium.org> Cr-Commit-Position: refs/heads/master@{#532544} [modify] https://crrev.com/4c353749ab3fb37cc4b8dd0f6693db4328c54ee5/chrome/android/javatests/src/org/chromium/chrome/browser/profiling_host/ProfilingProcessHostAndroidTest.java [modify] https://crrev.com/4c353749ab3fb37cc4b8dd0f6693db4328c54ee5/chrome/browser/profiling_host/profiling_process_host.cc [modify] https://crrev.com/4c353749ab3fb37cc4b8dd0f6693db4328c54ee5/chrome/browser/profiling_host/profiling_process_host.h [modify] https://crrev.com/4c353749ab3fb37cc4b8dd0f6693db4328c54ee5/chrome/browser/profiling_host/profiling_test_driver.cc [modify] https://crrev.com/4c353749ab3fb37cc4b8dd0f6693db4328c54ee5/chrome/common/profiling/profiling_client.cc [modify] https://crrev.com/4c353749ab3fb37cc4b8dd0f6693db4328c54ee5/chrome/common/profiling/profiling_client.h
,
Jan 31 2018
|
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by nedngu...@google.com
, Jan 22 2018Status: Assigned (was: Untriaged)