Multiple stories failing on [smoothness/thread_times].key_silk_cases android benchmarks |
|||||||||||||
Issue descriptionhttps://build.chromium.org/p/chromium.perf/builders/Android%20Nexus5X%20Perf/builds/465 Unexpected Failures: * smoothness.key_silk_cases/inbox_app.html?swipe_to_dismiss * smoothness.key_silk_cases/masonry.html Traceback (most recent call last): File "/b/swarming/w/ir/third_party/catapult/telemetry/telemetry/internal/story_runner.py", line 105, in _RunStoryAndProcessErrorIfNeeded state.RunStory(results) File "/b/swarming/w/ir/third_party/catapult/common/py_trace_event/py_trace_event/trace_event_impl/decorators.py", line 52, in traced_function return func(*args, **kwargs) File "/b/swarming/w/ir/third_party/catapult/telemetry/telemetry/page/shared_page_state.py", line 331, in RunStory self._current_page.Run(self) File "/b/swarming/w/ir/third_party/catapult/telemetry/telemetry/page/__init__.py", line 112, in Run self.RunPageInteractions(action_runner) File "/b/swarming/w/ir/tools/perf/page_sets/key_silk_cases.py", line 36, in RunPageInteractions self.PerformPageInteractions(action_runner) File "/b/swarming/w/ir/tools/perf/page_sets/key_silk_cases.py", line 312, in PerformPageInteractions self.SwipeToDismiss(action_runner) File "/b/swarming/w/ir/tools/perf/page_sets/key_silk_cases.py", line 309, in SwipeToDismiss element_function='document.getElementsByClassName("message")[2]') File "/b/swarming/w/ir/third_party/catapult/common/py_trace_event/py_trace_event/trace_event_impl/decorators.py", line 75, in traced_function return func(*args, **kwargs) File "/b/swarming/w/ir/third_party/catapult/telemetry/telemetry/internal/actions/action_runner.py", line 670, in SwipeElement speed_in_pixels_per_second=speed_in_pixels_per_second)) File "/b/swarming/w/ir/third_party/catapult/common/py_trace_event/py_trace_event/trace_event_impl/decorators.py", line 75, in traced_function return func(*args, **kwargs) File "/b/swarming/w/ir/third_party/catapult/telemetry/telemetry/internal/actions/action_runner.py", line 56, in _RunAction action.RunAction(self._tab) File "/b/swarming/w/ir/third_party/catapult/common/py_trace_event/py_trace_event/trace_event_impl/decorators.py", line 75, in traced_function return func(*args, **kwargs) File "/b/swarming/w/ir/third_party/catapult/telemetry/telemetry/internal/actions/swipe.py", line 89, in RunAction element_function=self._element_function) File "/b/swarming/w/ir/third_party/catapult/telemetry/telemetry/internal/actions/page_action.py", line 130, in EvaluateCallbackWithElement return tab.EvaluateJavaScript(code) File "/b/swarming/w/ir/third_party/catapult/common/py_trace_event/py_trace_event/trace_event_impl/decorators.py", line 75, in traced_function return func(*args, **kwargs) File "/b/swarming/w/ir/third_party/catapult/telemetry/telemetry/internal/browser/web_contents.py", line 168, in EvaluateJavaScript return self._inspector_backend.EvaluateJavaScript(*args, **kwargs) File "/b/swarming/w/ir/third_party/catapult/common/py_trace_event/py_trace_event/trace_event_impl/decorators.py", line 75, in traced_function return func(*args, **kwargs) File "/b/swarming/w/ir/third_party/catapult/telemetry/telemetry/internal/backends/chrome_inspector/inspector_backend.py", line 237, in EvaluateJavaScript return self._EvaluateJavaScript(expression, context_id, timeout) File "/b/swarming/w/ir/third_party/catapult/common/py_trace_event/py_trace_event/trace_event_impl/decorators.py", line 75, in traced_function return func(*args, **kwargs) File "/b/swarming/w/ir/third_party/catapult/telemetry/telemetry/internal/backends/chrome_inspector/inspector_backend.py", line 36, in inner return func(inspector_backend, *args, **kwargs) File "/b/swarming/w/ir/third_party/catapult/telemetry/telemetry/internal/backends/chrome_inspector/inspector_backend.py", line 501, in _EvaluateJavaScript return self._runtime.Evaluate(expression, context_id, timeout) File "/b/swarming/w/ir/third_party/catapult/telemetry/telemetry/internal/backends/chrome_inspector/inspector_runtime.py", line 54, in Evaluate description=details.get('exception', {}).get('description')) EvaluateException: UncaughtError: Error: Cannot find element: using element_function: document.getElementsByClassName("message")[2] at callback (<anonymous>:7:19) at <anonymous>:18:16
,
Sep 13 2017
Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/8968541333766230976
,
Sep 13 2017
=== BISECT JOB RESULTS === NO Test failure found Bisect Details Configuration: android_nexus5X_perf_bisect Benchmark : smoothness.key_silk_cases Metric : avg_surface_fps/masonry.html Revision Exit Code N chromium@497892 0 +- N/A 2 good chromium@497897 0 +- N/A 2 bad To Run This Test src/tools/perf/run_benchmark -v --browser=android-chromium --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests --story-filter=masonry.html smoothness.key_silk_cases More information on addressing performance regressions: http://g.co/ChromePerformanceRegressions Debug information about this bisect: https://chromeperf.appspot.com/buildbucket_job_status/8968541333766230976 For feedback, file a bug with component Speed>Bisection
,
Sep 13 2017
Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/8968539345794047184
,
Sep 13 2017
I once repro'd the failure locally on a N7gen2, but it didn't repro reliably. May be difficult to bisect.
,
Sep 13 2017
Hmm. It seems to fail so consistently on the waterfall though :/ Same 2 stories starting at the same time across all android skews. We have 2 short term solutions we can do right now. We can revert the change (might not be possible if we only support wprgo now) or we can just disable the 2 failing stories to green up the benchmark.
,
Sep 13 2017
=== BISECT JOB RESULTS === NO Test failure found Bisect Details Configuration: android_nexus5X_perf_bisect Benchmark : smoothness.key_silk_cases Metric : avg_surface_fps/masonry.html Revision Exit Code N chromium@497732 1 +- N/A 2 good chromium@498076 1 +- N/A 2 bad To Run This Test src/tools/perf/run_benchmark -v --browser=android-chromium --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests smoothness.key_silk_cases More information on addressing performance regressions: http://g.co/ChromePerformanceRegressions Debug information about this bisect: https://chromeperf.appspot.com/buildbucket_job_status/8968539345794047184 For feedback, file a bug with component Speed>Bisection
,
Sep 13 2017
It is not too late to revert. We still a couple of tests that haven't been migrated yet. That said, I think disabling to 2 failing stories would be better, because I don't have the expertise to diagnose the failure and fix it.
,
Sep 13 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/215ac0369f32bc5ced186a01b0f2ba007b09116c commit 215ac0369f32bc5ced186a01b0f2ba007b09116c Author: rnephew <rnephew@chromium.org> Date: Wed Sep 13 21:58:29 2017 [Telemetry] Disable 2 smoothness.key_silk_cases stories that are failing. Unexpected Failures: * smoothness.key_silk_cases/inbox_app.html?swipe_to_dismiss * smoothness.key_silk_cases/masonry.html Bug: 764825 Change-Id: I1cc38467f1c50067d692c18471b6466209e6d8bb Reviewed-on: https://chromium-review.googlesource.com/665392 Commit-Queue: rnephew <rnephew@chromium.org> Commit-Queue: Tien-Ren Chen <trchen@chromium.org> Reviewed-by: Tien-Ren Chen <trchen@chromium.org> Reviewed-by: Ned Nguyen <nednguyen@google.com> Cr-Commit-Position: refs/heads/master@{#501766} [modify] https://crrev.com/215ac0369f32bc5ced186a01b0f2ba007b09116c/tools/perf/benchmarks/smoothness.py
,
Sep 13 2017
Also seeing failures on thread_times.key_silk_cases so changing title to reflect that. Will disable on that benchmark as well.
,
Sep 13 2017
,
Sep 14 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/b043dd900a46ccae6b038f166e4f375b713fb3fb commit b043dd900a46ccae6b038f166e4f375b713fb3fb Author: rnephew <rnephew@chromium.org> Date: Thu Sep 14 00:21:07 2017 [Telemetry] Disable failing stories on thread_times.key_silk_cases android benchmark. TBR=nednguyen@google.com Bug: 764825 Change-Id: I8defe6ffd35db09da9bf8f64f45988de020b3d9f Reviewed-on: https://chromium-review.googlesource.com/666292 Reviewed-by: rnephew <rnephew@chromium.org> Commit-Queue: rnephew <rnephew@chromium.org> Cr-Commit-Position: refs/heads/master@{#501813} [modify] https://crrev.com/b043dd900a46ccae6b038f166e4f375b713fb3fb/tools/perf/benchmarks/thread_times.py
,
Sep 14 2017
When those were disabled, it triggered another story to start failing. This led me to dig into the code of the new failing test. I see it using ScrollToElement but never testing that the element exists, which is exactly the error we are seeing (the element not existing). I am wondering if the switch to wprgo has shook loose a bunch of race conditions. Instead of disabling this new story I am going to add some WaitForElement() checks before the scrolling and see if that works.
,
Sep 14 2017
After some local experimentation I really do not know what to make of this... Running: ./run_benchmark --browser=system --also-run-disabled-tests smoothness.key_silk_cases It gets to inbox_app.html?swipe_to_dismiss and then nothing loads. When running: ./run_benchmark --browser=system --also-run-disabled-tests smoothness.key_silk_cases --story_filter="swipe_to_dismiss" It loads just fine. (Note, running this on a linux box, thats why I'm running with --also-run-disabled-tests) This behavior reproduced 3/3 times. Interesting to note, it actually shows up first on font_wipe every time. But that story has no interaction and passes even though the page never loads. I confirmed this on a nexus 5x running 8.0.0 OPR1.17.... using the chrome that came bundled with it. Its starting to smell more like a problem with wprgo/telemetry than anything in the benchmark or with the wprgo recording itself. Ned, who should I add for looking into wprgo related problems?
,
Sep 14 2017
Helen: can you give Randy some step to verify if it's WPRGO problem?
,
Sep 14 2017
,
Sep 14 2017
I see the behavior locally on my Linux box as well. It doesn't seem to be a WprGo problem because the page loads fine when --story-filter is specified. I suspect it is in telemetry. Could you check if "third_party/catapult/telemetry/telemetry/internal/util/webpagereplay_go_server.py" is started successfully? and get the logs at |_temp_log_file_path| ? I am running out of time today. If you don't find any leads there, I can take a look tomorrow.
,
Sep 14 2017
I added logging to the webpagereplay_go_server.py methods StartServer, StopServer, and commented out the deletion of the temp log file. When running the full set of logs I get the output like I expect to get: .... [ RUN ] http://groupcloned.com/test/plain/list-recycle-transform.html --------------------RNEPHEW: starting server for wpr /tmp/tmpMbtrOp [ OK ] http://groupcloned.com/test/plain/list-recycle-transform.html (25921 ms) [ RUN ] list_animation_simple.html [ OK ] list_animation_simple.html (18462 ms) [ RUN ] http://groupcloned.com/test/plain/sticky-using-webkit-backface-visibility.html [ OK ] http://groupcloned.com/test/plain/sticky-using-webkit-backface-visibility.html (18611 ms) [ RUN ] http://jsfiddle.net/3yDKh/15/show/ --------------------RNEPHEW: stopping server for wpr --------------------RNEPHEW: Please delete /tmp/tmpMbtrOp --------------------RNEPHEW: starting server for wpr /tmp/tmp48bJhr [ OK ] http://jsfiddle.net/3yDKh/15/show/ (19574 ms) [ RUN ] http://jsfiddle.net/jx5De/14/show/ [ OK ] http://jsfiddle.net/jx5De/14/show/ (20546 ms) [ RUN ] http://jsfiddle.net/3yDKh/16/show/ [ OK ] http://jsfiddle.net/3yDKh/16/show/ (19591 ms) [ RUN ] http://jsfiddle.net/R8DX9/4/show/ [ OK ] http://jsfiddle.net/R8DX9/4/show/ (199431 ms) [ RUN ] http://jsfiddle.net/rF9Gh/7/show/ [ OK ] http://jsfiddle.net/rF9Gh/7/show/ (18863 ms) [ RUN ] http://jsfiddle.net/TLXLu/3/show/ [ OK ] http://jsfiddle.net/TLXLu/3/show/ (20057 ms) [ RUN ] http://jsfiddle.net/cKB9D/7/show/ [ OK ] http://jsfiddle.net/cKB9D/7/show/ (20375 ms) [ RUN ] http://jsfiddle.net/vBQHH/11/show/ [ OK ] http://jsfiddle.net/vBQHH/11/show/ (21202 ms) [ RUN ] http://jsfiddle.net/ugkd4/10/show/ [ OK ] http://jsfiddle.net/ugkd4/10/show/ (21484 ms) [ RUN ] http://jsfiddle.net/xLuvC/1/show/ [ OK ] http://jsfiddle.net/xLuvC/1/show/ (20800 ms) [ RUN ] http://jsfiddle.net/bNp2h/3/show/ --------------------RNEPHEW: stopping server for wpr --------------------RNEPHEW: Please delete /tmp/tmp48bJhr Note: It doesn't restart the server each time because the stories are on the same wprgo archive file. Logs from failing running: rnephew@rnephew0:/tmp$ cat tmpvqdhQn 2017/09/14 15:45:55 Loading cert from /usr/local/google/home/rnephew/chromium/clank2/src/third_party/catapult/web_page_replay_go/wpr_cert.pem 2017/09/14 15:45:55 Loading key from /usr/local/google/home/rnephew/chromium/clank2/src/third_party/catapult/web_page_replay_go/wpr_key.pem 2017/09/14 15:45:55 Loading script from /usr/local/google/home/rnephew/chromium/clank2/src/third_party/catapult/web_page_replay_go/deterministic.js 2017/09/14 15:45:55 Opened archive /usr/local/google/home/rnephew/chromium/clank2/src/tools/perf/page_sets/data/key_silk_cases_015.wprgo 2017/09/14 15:45:55 Use Ctrl-C to exit. 2017/09/14 15:45:55 Starting server on http://127.0.0.1:43639 2017/09/14 15:45:55 Starting server on https://127.0.0.1:43048 2017/09/14 15:46:00 ServeHTTP(http://jsfiddle.net/bNp2h/3/show/): serving 200 response 2017/09/14 15:46:00 ServeHTTP(http://jsfiddle.net/js/lib/dummy.js): serving 200 response 2017/09/14 15:46:00 ServeHTTP(http://jsfiddle.net/css/result-light.css): serving 200 response 2017/09/14 15:46:00 ServeHTTP(http://jankfree.org/silk/restaurant_icon.png): serving 200 response 2017/09/14 15:46:00 ServeHTTP(http://jankfree.org/silk/maps_icon.png): serving 200 response 2017/09/14 15:46:00 ServeHTTP(http://jankfree.org/silk/momofuku_noodle_bar.jpg): serving 200 response 2017/09/14 15:46:00 ServeHTTP(http://jsfiddle.net/favicon.ico): serving 200 response 2017/09/14 15:46:20 ServeHTTP(http://127.0.0.1:39066/font_wipe.html): couldn't find matching request: not found 2017/09/14 15:46:20 ServeHTTP(http://127.0.0.1:39066/favicon.ico): couldn't find matching request: not found 2017/09/14 15:46:39 ServeHTTP(http://127.0.0.1:39066/inbox_app.html?stress_hidey_bars): couldn't find matching request: not found 2017/09/14 15:46:39 ServeHTTP(http://127.0.0.1:39066/favicon.ico): couldn't find matching request: not found 2017/09/14 15:48:10 ServeHTTP(http://127.0.0.1:39066/inbox_app.html?toggle_drawer): couldn't find matching request: not found 2017/09/14 15:48:10 ServeHTTP(http://127.0.0.1:39066/favicon.ico): couldn't find matching request: not found When I run it with --story-filter=inbox_app I get: [ RUN ] inbox_app.html?swipe_to_dismiss ===== SKIPPING TEST inbox_app.html?swipe_to_dismiss: crbug.com/764825 ===== [ OK ] inbox_app.html?swipe_to_dismiss (1 ms) [ RUN ] inbox_app.html?stress_hidey_bars (WARNING) 2017-09-14 15:58:09,113 model._CreateImporters:274 No importer found for TraceDataPart("telemetry") [ OK ] inbox_app.html?stress_hidey_bars (26759 ms) [ RUN ] inbox_app.html?toggle_drawer (WARNING) 2017-09-14 15:58:31,868 model._CreateImporters:274 No importer found for TraceDataPart("telemetry") [ OK ] inbox_app.html?toggle_drawer (21862 ms) [ RUN ] inbox_app.html?slide_drawer ===== SKIPPING TEST inbox_app.html?slide_drawer: crbug.com/446332 ===== [ OK ] inbox_app.html?slide_drawer (0 ms) [ PASSED ] 4 tests. Because of this I strongly suspect that when we run with --story-filter we are running a completely different codepath. Is it possible we are using the old wpr in catapult/telemetry/telemetry/internal/util/wpr_server.py? I tried adding similar logging to the methods there, but they never showed up either.
,
Sep 15 2017
Hmm.. The swipe_to_dismiss story is using file:// url, so it doesn't go through the network/WPR. Ned, what's special about these file:// urls? How are they handled in Telemetry? file://key_silk_cases/inbox_app.html?swipe_to_dismiss https://cs.chromium.org/chromium/src/tools/perf/page_sets/key_silk_cases.py?rcl=81f36557132aca322a50f4e7d44def8b3c3d4439&l=301
,
Sep 15 2017
In the logs I see: 2017/09/14 15:46:20 ServeHTTP(http://127.0.0.1:39066..... and 2017/09/14 15:45:55 Starting server on http://127.0.0.1:43639 2017/09/14 15:45:55 Starting server on https://127.0.0.1:43048 Is the fact that its using different ports a problem? Or is the android forwarder the bridge there? I dont recall it using 'file://' Wasn't it using '127.0.0.1', as shown in the wprgo logs? I know thats localhost, but I dont know enough about the network stack to know if theres any difference between that and file://.
,
Sep 15 2017
Ohh.., the way Telemetry handle file:// url is that it would start a local server (https://cs.chromium.org/chromium/src/third_party/catapult/telemetry/telemetry/page/shared_page_state.py?rcl=49fbcfa16b5d148a595cc50036d5e8354739f13f&l=303). tsproxy then would look for the localhost url choose to forward the message to original destination instead of specified desthost (which is WPRGo in this case) (https://github.com/catapult-project/catapult/blob/master/telemetry/third_party/tsproxy/tsproxy.py#L325)
,
Sep 15 2017
So if I'm understanding correctly then, based off the logs and Neds last comment: The WPRGo server shouldn't be getting those 127.0.0.1 requests then, but is?
,
Sep 15 2017
> The WPRGo server shouldn't be getting those 127.0.0.1 requests then, but is? That would be my understanding as well. This following line is from WPRGO: 2017/09/14 15:46:39 ServeHTTP(http://127.0.0.1:39066/inbox_app.html?stress_hidey_bars): couldn't find matching request: not found inbox_app.html should be served from that local server and not from WPRGO
,
Sep 15 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/d028601991101ebd2308eb8ce3af47af71cf0783 commit d028601991101ebd2308eb8ce3af47af71cf0783 Author: rnephew <rnephew@chromium.org> Date: Fri Sep 15 22:26:37 2017 [Telemetry] make key_silk_cases stress_hidey_bars test wait for element before scrolling. Bug: 764825 Change-Id: I37a61df99272cb9ac2e96a404a06d89b006dcd9f Reviewed-on: https://chromium-review.googlesource.com/667739 Reviewed-by: Ned Nguyen <nednguyen@google.com> Reviewed-by: Victor Miura <vmiura@chromium.org> Commit-Queue: rnephew <rnephew@chromium.org> Cr-Commit-Position: refs/heads/master@{#502405} [modify] https://crrev.com/d028601991101ebd2308eb8ce3af47af71cf0783/tools/perf/page_sets/key_silk_cases.py
,
Sep 18 2017
The fact that Telemetry can no longer handle static page & WPRGO page in a same run seems serious. I will take a look.
,
Sep 18 2017
After adding some logging to tsproxy, I am pretty sure that this is bug in tsproxy. The proxy server still forward localhost request to the WPRGO server although the URL are static URL. Upon navigating static pages like inbox_app.html?swipe_to_dismiss, I still see tsproxy trying to forward the request to wprgo server: ... 13:28:41.918 - [65] Connecting to 127.0.0.1:53113 13:28:41.918 - [66] New Socks5 client 13:28:41.918 - [65] Connected 13:28:41.918 - [66] Connecting to 127.0.0.1:53113 13:28:41.919 - [66] Connected ... (53113 is WPRGO's HTTPS port) To reproduce this: Patch https://chromium-review.googlesource.com/c/chromium/src/+/671505 (for modifying the benchmark) Patch https://codereview.chromium.org/3015573002 (for TsProxy logging) Run: ./tools/perf/run_benchmark --browser=system smoothness.key_silk_cases During the run, Telemetry will shows message like: "Pipe tsproxy log to /var/folders/vy/5803p20d5l55ytg52v9f04v00052sf/T/tmpJ0xRB3". Once this happens, you can run "tail -f /var/folders/vy/5803p20d5l55ytg52v9f04v00052sf/T/tmpJ0xRB3" in another termninal window to see tsproxy log. Patrick: can you take a look at this?
,
Sep 18 2017
Yep, I'll take a look in the morning and see if I can reproduce it. Does it need a Phone to reproduce or does it also reproduce on a desktop?
,
Sep 18 2017
You can apply my CLs reproduce it on desktop.
,
Sep 19 2017
I just committed a fix for the tsproxy port rewriting issue: https://github.com/WPO-Foundation/tsproxy/commit/c35950686c14ca27306bfc303fcf7139e3b3d912 After the first connection to localhost it would start rewriting them to go to WPR. Ned, can you pull it into telemetry and roll the update and see if it fixes the remaining issues?
,
Sep 19 2017
,
Sep 19 2017
I can verify that the latest version of tsproxy fixes the problem. Thanks Patrick! Roll CL: https://codereview.chromium.org/3015623002/
,
Sep 19 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/933071e48a47887e8b728b8183af8391125ee4ff commit 933071e48a47887e8b728b8183af8391125ee4ff Author: catapult-deps-roller@chromium.org <catapult-deps-roller@chromium.org> Date: Tue Sep 19 21:21:16 2017 Roll src/third_party/catapult/ 8380d62bc..ab30bb20a (2 commits) https://chromium.googlesource.com/external/github.com/catapult-project/catapult.git/+log/8380d62bc249..ab30bb20a857 $ git log 8380d62bc..ab30bb20a --date=short --no-merges --format='%ad %ae %s' 2017-09-19 xunjieli Apply Chromium changes up to commit 0036296a1128ac9cbefeaff51c8df831ec421c36 2017-09-19 nednguyen Roll tsproxy to the latest version Created with: roll-dep src/third_party/catapult BUG= #762686 , 764825 Documentation for the AutoRoller is here: https://skia.googlesource.com/buildbot/+/master/autoroll/README.md If the roll is causing failures, see: http://www.chromium.org/developers/tree-sheriffs/sheriff-details-chromium#TOC-Failures-due-to-DEPS-rolls CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel TBR=sullivan@chromium.org Change-Id: I95d0f20d306fbba29c1ebcc63bb0db563e367c4a Reviewed-on: https://chromium-review.googlesource.com/673380 Reviewed-by: <catapult-deps-roller@chromium.org> Commit-Queue: <catapult-deps-roller@chromium.org> Cr-Commit-Position: refs/heads/master@{#502951} [modify] https://crrev.com/933071e48a47887e8b728b8183af8391125ee4ff/DEPS
,
Sep 20 2017
,
Sep 20 2017
I need to reenable the stories before marking this as fixed.
,
Sep 20 2017
The revert doesn't come clean. I will do it manually.
,
Sep 20 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/4a59b5f72962a79f5c6bb80a5a6ce6fb9d7f3f9e commit 4a59b5f72962a79f5c6bb80a5a6ce6fb9d7f3f9e Author: Ned Nguyen <nednguyen@google.com> Date: Wed Sep 20 14:09:19 2017 Reenable failed stories in smoothness.key_silk_cases The root cause is believed to be fixed. TBR=rnephew@chromium.org Bug: 764825 , 507865 , 338838 , 446332 Change-Id: Ia670ad38379c5cd7c036ae2dd3ebc4bde76d6687 Reviewed-on: https://chromium-review.googlesource.com/674807 Commit-Queue: Ned Nguyen <nednguyen@google.com> Reviewed-by: Ned Nguyen <nednguyen@google.com> Cr-Commit-Position: refs/heads/master@{#503130} [modify] https://crrev.com/4a59b5f72962a79f5c6bb80a5a6ce6fb9d7f3f9e/tools/perf/benchmarks/smoothness.py
,
Sep 22 2017
Only smoothness.key_silk_cases/inbox_app.html?slide_drawer is failing On Nexus 5, so I think the root cause of the mass failure is addressed. I will leave smoothness.key_silk_cases/inbox_app.html?slide_drawer failure On Nexus 5 to sheriff |
|||||||||||||
►
Sign in to add a comment |
|||||||||||||
Comment 1 by rnep...@chromium.org
, Sep 13 2017Owner: trchen@chromium.org
Status: Assigned (was: Untriaged)