ParameterizedWebFrameTest.CallingPostPausableTaskWhilePaused flaked on Android |
||||
Issue descriptionC 424.219s Main [ RUN ] All/ParameterizedWebFrameTest.CallingPostPausableTaskWhilePaused/0 C 424.219s Main [INFO:SkFontMgr_android_parser.cpp(625)] [SkFontMgr Android Parser] '/system/etc/fonts.xml' could not be opened C 424.219s Main C 424.219s Main [INFO:SkFontMgr_android_parser.cpp(625)] [SkFontMgr Android Parser] '/vendor/etc/fallback_fonts.xml' could not be opened C 424.219s Main C 424.219s Main ../../third_party/WebKit/Source/core/exported/WebFrameTest.cpp:648: Failure C 424.219s Main Value of: callback_helper.result() C 424.219s Main Actual: false C 424.219s Main Expected: true C 424.219s Main [ FAILED ] All/ParameterizedWebFrameTest.CallingPostPausableTaskWhilePaused/0, where GetParam() = false (101 ms)
,
Jan 24 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/c3627e8a96c6e29083e376ebd3fb8f18c35ab9bf commit c3627e8a96c6e29083e376ebd3fb8f18c35ab9bf Author: Joe Downing <joedow@chromium.org> Date: Wed Jan 24 23:02:35 2018 Disabling flaky test: CallingPostPausableTaskWhilePaused on Android I see sporadic failures going back several days so I am going to disable this test. TBR=jbudorick@chromium.org BUG=804892 Change-Id: I55f9af5935e7eb200c3cf963df2d7ce05dc3b991 Reviewed-on: https://chromium-review.googlesource.com/884392 Reviewed-by: Joe Downing <joedow@chromium.org> Commit-Queue: Joe Downing <joedow@chromium.org> Cr-Commit-Position: refs/heads/master@{#531733} [modify] https://crrev.com/c3627e8a96c6e29083e376ebd3fb8f18c35ab9bf/third_party/WebKit/Source/core/exported/WebFrameTest.cpp
,
Jan 25 2018
This test was added in https://chromium-review.googlesource.com/807346, so assigning to rdevlin.cronin@ and guessing the component to get it out of Blink>Infra triage.
,
Jan 26 2018
[Extensions Triage] Marking as assigned.
,
Jan 26 2018
+dcheng@, haraken@, jbroman@ from the original patch. I sadly have no idea about android + blink - any ideas here?
,
Jan 31 2018
Without having dug too deeply, two thoughts: 1. Maybe something about the way the timer task is scheduled (through the various indirections implied by the timer task runner) cause the exit-run-loop task to sometime be ordered before the timer task. 2. (less likely) Maybe the exit-run-loop task is targeting some inner run loop somewhere. If it's just (1), one fix might be to have the test complete by using ExitRunLoop (though really we ought to be capturing the QuitClosure of the real base run loop, to be less deprecated). If it's (2), then maybe tweaking RunPendingTasks to explicitly make a base::RunLoop and post its quit closure instead of the one that looks up the present top RunLoop would work. Of course, reproing would determine exactly what is happening. |
||||
►
Sign in to add a comment |
||||
Comment 1 by joedow@chromium.org
, Jan 24 2018