Issue metadata
Sign in to add a comment
|
serialize-nested-array.html failing on perf bots |
||||||||||||||||||||||
Issue descriptionAccording to https://codereview.chromium.org/2553993002 the test is supposed to fail when stack usage regresses. The failure started here: https://build.chromium.org/p/chromium.perf/builders/Win%2010%20Perf/builds/863 FATAL: Got an exception while running test.run with name=RangeError, message=Maximum call stack size exceeded Traceback (most recent call last): File "c:\b\s\w\ir\third_party\catapult\telemetry\telemetry\internal\story_runner.py", line 90, in _RunStoryAndProcessErrorIfNeeded state.RunStory(results) File "c:\b\s\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 "c:\b\s\w\ir\third_party\catapult\telemetry\telemetry\page\shared_page_state.py", line 298, in RunStory self._current_page, self._current_tab, results) File "c:\b\s\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 "c:\b\s\w\ir\tools\perf\benchmarks\blink_perf.py", line 227, in ValidateAndMeasurePage results.current_page, metric, units, values)) File "c:\b\s\w\ir\third_party\catapult\telemetry\telemetry\value\list_of_scalar_values.py", line 83, in __init__ assert len(values) > 0 AssertionError I don't see any v8 rolls in that build (assuming I identified the first failing run correctly), but there are two catapult rolls.
,
May 30 2017
I kicked off a return_code bisect to see if we can figure out what CL it failed at. Note that it started passing again at build 875: https://build.chromium.org/p/chromium.perf/builders/Win%2010%20Perf/builds/875
,
May 31 2017
=== BISECT JOB RESULTS === Test failure found with culprit Suspected Commit Author : sebmarchand Commit : 833aa96095e1f827ffc05af8bf545a094ffa6e35 Date : Sat May 27 01:34:31 2017 Subject: Changing default Windows compiler to VS2017 Bisect Details Configuration: winx64_10_perf_bisect Benchmark : blink_perf.bindings Metric : serialize-nested-array/serialize-nested-array Revision Exit Code N chromium@475131 0 +- N/A 20 good chromium@475178 0 +- N/A 20 good chromium@475202 0 +- N/A 20 good chromium@475208 0 +- N/A 20 good chromium@475211 0 +- N/A 20 good chromium@475212 1 +- N/A 20 bad <-- chromium@475213 1 +- N/A 20 bad chromium@475214 1 +- N/A 20 bad chromium@475225 1 +- N/A 20 bad To Run This Test src/tools/perf/run_benchmark -v --browser=release_x64 --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests blink_perf.bindings Debug Info https://chromeperf.appspot.com/buildbucket_job_status/8978155461908823328 Is this bisect wrong? https://chromeperf.appspot.com/bad_bisect?try_job_id=5788099537272832 | O O | Visit http://www.chromium.org/developers/speed-infra/perf-bug-faq | X | for more information addressing perf regression bugs. For feedback, | / \ | file a bug with component Speed>Bisection. Thank you!
,
May 31 2017
sebmarchand: FYI, looks like there is also a regression in stack usage with the VS2017 compiler.
,
May 31 2017
Re-assigning to Bruce.
,
Jun 22 2017
I tested this with a local 64-bit release build with the latest (Update 3 version 2) of the VC++ 2017 compiler, comparing it to VC++ 2015. With VC++ 2015 I could push the 'length' field in serialize-nested-array.html up to 1740 without hitting the failure. With VC++ 2017 I could push the 'length' field up to *1900* without a failure. I suppose it's possible that the updated version of VC++ 2017 fixed the issue but I'm not entirely convinced. This bot was red before the most recent so I had to hand examine the build failures looking for serialize-nested-array: https://build.chromium.org/p/chromium.perf/builders/Win%2010%20Perf/builds/954 - 961 were all clean. I'm going to close as WontFix. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by 42576172...@developer.gserviceaccount.com
, May 30 2017