New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 618684 link

Starred by 1 user

Issue metadata

Status: Duplicate
Merged: issue 616941
Owner:
Last visit > 30 days ago
Closed: Jun 2016
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug-Regression



Sign in to add a comment

3% regression in page_cycler.intl_ko_th_vi at 397200:397257

Project Member Reported by pmeenan@chromium.org, Jun 9 2016

Issue description

See the link to graphs below.
 
All graphs for this bug:
  https://chromeperf.appspot.com/group_report?bug_id=618684

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICg3KqgugoM


Bot(s) for this bug's original alert(s):

android-nexus7v2
Project Member

Comment 2 by 42576172...@developer.gserviceaccount.com, Jun 10 2016

Mergedinto: 616941
Status: Duplicate (was: Assigned)

===== BISECT JOB RESULTS =====
Status: completed


===== SUSPECTED CL(s) =====
Subject : Track DisplayItemClient aliveness for each PaintController
Author  : wangxianzhu
Commit description:
  
After CHECK_DISPLAY_ITEM_CLIENT_ALIVENESS was enabled, we didn't get
crashes in DisplayItemClient::~DisplayItemClient() when the
DisplayItemClient should be alive. We still get crashes in
PaintController::updateCacheGeneration() [1]
which indicates that we still have short-lived DisplayItemClient but
not catched by aliveness checking. This might happen if there are
multiple PaintControllers (e.g. one created by SkPictureBuilder and
another by GraphicsLayer).

Separately track DisplayItemClient aliveness for each PaintController
in order to catch the issue.

[1] https://crash.corp.google.com/browse?q=custom_data.ChromeCrashProto.ptype%3D%27renderer%27%20AND%20custom_data.ChromeCrashProto.magic_signature_1.name%20like%20%27blink%3A%3APaintController%3A%3A%25%27%20AND%20product.version%3D%2753.0.2751.0%27&ignore_case=false&enable_rewrite=true&omit_field_name=&omit_field_value=&omit_field_opt=%3D&stbtiq=&reportid=20bc8a5c00000000&index=2#4

BUG=609218

Review-Url: https://codereview.chromium.org/2031623002
Cr-Commit-Position: refs/heads/master@{#397243}
Commit  : 53559da8fd5faa99d30a00eadbc6da3aebbde2b1
Date    : Wed Jun 01 21:16:57 2016


===== TESTED REVISIONS =====
Revision         Mean     Std Dev  N  Good?
chromium@397199  6394.74  21.3461  6  good
chromium@397228  6388.86  19.5728  5  good
chromium@397236  6396.46  13.6008  5  good
chromium@397240  6375.67  15.7218  5  good
chromium@397242  6362.46  22.346   5  good
chromium@397243  6471.99  26.0644  5  bad    <--
chromium@397257  6441.16  25.0325  8  bad

Bisect job ran on: android_nexus7_perf_bisect
Bug ID: 618684

Test Command: src/tools/perf/run_benchmark -v --browser=android-chromium --output-format=chartjson --upload-results --also-run-disabled-tests page_cycler.intl_ko_th_vi
Test Metric: cold_times/page_load_time
Relative Change: 0.71%
Score: 99.9

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/android_nexus7_perf_bisect/builds/3003
Job details: https://chromeperf.appspot.com/buildbucket_job_status/9010327720184216912


Not what you expected? We'll investigate and get back to you!
  https://chromeperf.appspot.com/bad_bisect?try_job_id=5865911303536640

| 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 Tests>AutoBisect.  Thank you!

Sign in to add a comment