Issue metadata
Sign in to add a comment
|
system_health.memory_mobile flakily failing for unknown reason |
||||||||||||||||||||||
Issue descriptionRevision range first seen: ????? Link to failing step log: https://luci-logdog.appspot.com/v/?s=chrome%2Fbb%2Fchromium.perf%2FAndroid_Nexus5_Perf__1_%2F5239%2F%2B%2Frecipes%2Fsteps%2Fsystem_health.memory_mobile%2F0%2Fstdout This failure appears to be happening for at least a couple different stories, but may be happening for all stories. Example stories are: load:news:sohu - https://luci-logdog.appspot.com/v/?s=chrome%2Fbb%2Fchromium.perf%2FAndroid_Nexus5_Perf__1_%2F5239%2F%2B%2Frecipes%2Fsteps%2Fsystem_health.memory_mobile%2F0%2Fstdout Failure screenshot: https://console.developers.google.com/m/cloudstorage/b/chrome-telemetry-output/o/profiler-file-id_149-2017-02-12_18-56-5359011.png load:news:nytimes - https://luci-logdog.appspot.com/v/?s=chrome%2Fbb%2Fchromium.perf%2FAndroid_Nexus5_Perf__1_%2F5240%2F%2B%2Frecipes%2Fsteps%2Fsystem_health.memory_mobile%2F0%2Fstdout Failure screenshot: https://console.developers.google.com/m/cloudstorage/b/chrome-telemetry-output/o/profiler-file-id_145-2017-02-13_00-10-4218101.png What's interesting here is that, in both cases, the tests appear to be failing due to Chrome crashes (e.g. WebSocketConnectionClosedException: Connection is already closed.). However, in both cases, the failure screenshots indicate that the browser is still alive. nednguyen@, can you think of any situations where we have WebSocketConnectionClosedExceptions where the browser screenshot seems to indicate that the browser is still alive?
,
Feb 13 2017
(swapping out nednguyen@'s accounts)
,
Feb 13 2017
Could this be a bug in how memory dump command is implemented? What happened here is the socket connection between Telemetry & Chrome is closed before Telemetry receives the response from Chrome after it sends 'Tracing.requestMemoryDump' memory-infra folks: any opinion?
,
Feb 13 2017
I'm going to kick off a bisect on this: it seems like load:news:sohu started failing much more frequently recently, and it seems like there's a particular revision range where that may have started.
,
Feb 13 2017
Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/8987747008189785616
,
Feb 13 2017
=== BISECT JOB RESULTS === NO Test failure found Bisect Details Configuration: android_nexus5_perf_bisect Benchmark : system_health.memory_mobile Metric : memory:chrome:all_processes:process_count_avg/load_news/load_news_sohu Revision Exit Code N chromium@449736 0 +- N/A 5 good chromium@449841 0 +- N/A 5 bad Please refer to the following doc on diagnosing memory regressions: https://chromium.googlesource.com/chromium/src/+/master/docs/memory-infra/memory_benchmarks.md 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=load.news.sohu system_health.memory_mobile Debug Info https://chromeperf.appspot.com/buildbucket_job_status/8987747008189785616 Is this bisect wrong? https://chromeperf.appspot.com/bad_bisect?try_job_id=6669481088122880 | 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!
,
Oct 16 2017
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 Deleted