bisect started at https://chromeperf.appspot.com/buildbucket_job_status/9017365074546729664

Previous bisect failed with "Uncaught Exception".

Started 2 new bisects, one for each test
- rasterize_and_record_micro.key_mobile_sites_smooth: https://chromeperf.appspot.com/buildbucket_job_status/9017353681392193744
- rasterize_and_record_micro.top_25_smooth: https://chromeperf.appspot.com/buildbucket_job_status/9017353584243284976

Prasad and Roberto, can you help to take a look at the bisect jobs? Why do they fail with uncaught exceptions?

 Issue 597589  has been merged into this issue.

@Prasad: can you look into the bisect issue? This is blocking cluster telemetry benchmarks from running, so the bisect should be fixed for us to figure out the culprit CL as soon as possible.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/1b9ba3a73f704481805e775df401a5bfd21ee3a9

commit 1b9ba3a73f704481805e775df401a5bfd21ee3a9
Author: zhenw <zhenw@chromium.org>
Date: Thu Mar 24 20:21:02 2016

Disable 2 rasterize_and_record_micro benchmarks on Linux

BUG= 597391 
CQ_EXTRA_TRYBOTS=tryserver.chromium.perf:winx64_10_perf_cq;tryserver.chromium.perf:mac_retina_perf_cq;tryserver.chromium.perf:linux_perf_cq
TBR=nednguyen@google.com

Review URL: https://codereview.chromium.org/1831023002

Cr-Commit-Position: refs/heads/master@{#383130}

[modify] https://crrev.com/1b9ba3a73f704481805e775df401a5bfd21ee3a9/tools/perf/benchmarks/rasterize_and_record_micro.py

I believe this should still be P1 because as https://bugs.chromium.org/p/chromium/issues/detail?id=597391#c5 detailed it is still blocking CT.

OK, the bisect job failed due to   crbug.com/597655 . The patch causing bisect failure was reverted.

Bisect restarted: https://chromeperf.appspot.com/buildbucket_job_status/9017182656258775600

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


===== TESTED REVISIONS =====
Revision                Exit Code   Std. Dev.   Num Values  Good?
chromium@382778         1           N/A         5           good
chromium@382798         1           N/A         5           bad

Bisect job ran on: linux_perf_bisect
Bug ID: 597391

Test Command: src/tools/perf/run_benchmark -v --browser=release --output-format=chartjson --also-run-disabled-tests rasterize_and_record_micro.key_mobile_sites_smooth
Test Metric: pixels_rasterized/http___news.yahoo.com
Relative Change: 0.00%
Score: 0

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/linux_perf_bisect/builds/6358
Job details: https://chromeperf.appspot.com/buildbucket_job_status/9017182656258775600


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

| 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!

Hmhh, since this is failing flakily, can we kick of a return code bisect with pageset-repeat=5?

I kicked off another bisect return code job here: https://chromeperf.appspot.com/buildbucket_job_status/9017177003039382032

=== Auto-CCing suspected CL author wkorman@chromium.org ===

Hi wkorman@chromium.org, the bisect results pointed to your CL below as possibly
causing a regression. Please have a look at this info and see whether
your CL be related.


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


===== SUSPECTED CL(s) =====
Subject : Make GraphicsLayer the DisplayItemClient for scrollbars composited via PaintLayerCompositor.
Author  : wkorman
Commit description:
  
Currently, the DisplayItemClient is LayoutScrollbarPart. This has two
problems: the mapping between the LayoutScrollbarPart and its backing
is hard to reverse-engineer given the way the scrollbar code is set
up (LayoutScrollbarPart vs Scrollbar vs ScrollableArea), and the
fact that LayoutScrollbarPart can be painted in both non-composited
and composited modes. This distinction is important for computation
of correct visual rects.

This can be cleaned up by replaying the painted scrollbar content
with the GraphicsLayer backing as the DisplayItemClient, which
has the correct visualRect() (i.e. bounds of GraphicsLayer).

BUG= 529938 

Review URL: https://codereview.chromium.org/1825193002

Cr-Commit-Position: refs/heads/master@{#382778}
Commit  : 8460ef8fc6125185abc1486eb61b0ca7fc9298ad
Date    : Wed Mar 23 03:14:44 2016


===== TESTED REVISIONS =====
Revision                Exit Code   Std. Dev.   Num Values  Good?
chromium@382774         0           N/A         5           good
chromium@382776         0           N/A         5           good
chromium@382777         0           N/A         5           good
chromium@382778         1           N/A         5           bad         <-
chromium@382781         1           N/A         5           bad
chromium@382787         1           N/A         5           bad
chromium@382800         1           N/A         5           bad

Bisect job ran on: linux_perf_bisect
Bug ID: 597391

Test Command: src/tools/perf/run_benchmark -v --browser=release --output-format=chartjson --also-run-disabled-tests rasterize_and_record_micro.top_25_smooth
Test Metric: record_time/record_time
Relative Change: Zero to non-zero
Score: 99.9

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/linux_perf_bisect/builds/6360
Job details: https://chromeperf.appspot.com/buildbucket_job_status/9017177003039382032


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

| 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!

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/4cd3a57d676a70d046b3d190a701ecb6db74a112

commit 4cd3a57d676a70d046b3d190a701ecb6db74a112
Author: nednguyen <nednguyen@google.com>
Date: Sat Mar 26 05:39:21 2016

Revert of Disable 2 rasterize_and_record_micro benchmarks on Linux (patchset #1 id:1 of https://codereview.chromium.org/1831023002/ )

Reason for revert:
See if the revert in https://codereview.chromium.org/1839533002/ fix the crash.

Original issue's description:
> Disable 2 rasterize_and_record_micro benchmarks on Linux
>
> BUG= 597391 
> CQ_EXTRA_TRYBOTS=tryserver.chromium.perf:winx64_10_perf_cq;tryserver.chromium.perf:mac_retina_perf_cq;tryserver.chromium.perf:linux_perf_cq
> TBR=nednguyen@google.com
>
> Committed: https://crrev.com/1b9ba3a73f704481805e775df401a5bfd21ee3a9
> Cr-Commit-Position: refs/heads/master@{#383130}

TBR=zhenw@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG= 597391 

Review URL: https://codereview.chromium.org/1834043003

Cr-Commit-Position: refs/heads/master@{#383447}

[modify] https://crrev.com/4cd3a57d676a70d046b3d190a701ecb6db74a112/tools/perf/benchmarks/rasterize_and_record_micro.py

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/043ab27b4a422d665580b12b588cba2d47afc387

commit 043ab27b4a422d665580b12b588cba2d47afc387
Author: nednguyen <nednguyen@google.com>
Date: Sat Mar 26 07:30:24 2016

Revert of Make GraphicsLayer the DisplayItemClient for scrollbars composited via PaintLayerCompositor. (patchset #6 id:100001 of https://codereview.chromium.org/1825193002/ )

Reason for revert:
Speculative revert: this may cause crash for rasterize_and_record_micro benchmark.

BUG= 597391 

Original issue's description:
> Make GraphicsLayer the DisplayItemClient for scrollbars composited via PaintLayerCompositor.
>
> Currently, the DisplayItemClient is LayoutScrollbarPart. This has two
> problems: the mapping between the LayoutScrollbarPart and its backing
> is hard to reverse-engineer given the way the scrollbar code is set
> up (LayoutScrollbarPart vs Scrollbar vs ScrollableArea), and the
> fact that LayoutScrollbarPart can be painted in both non-composited
> and composited modes. This distinction is important for computation
> of correct visual rects.
>
> This can be cleaned up by replaying the painted scrollbar content
> with the GraphicsLayer backing as the DisplayItemClient, which
> has the correct visualRect() (i.e. bounds of GraphicsLayer).
>
> BUG= 529938 
>
> Committed: https://crrev.com/8460ef8fc6125185abc1486eb61b0ca7fc9298ad
> Cr-Commit-Position: refs/heads/master@{#382778}

TBR=chrishtr@chromium.org,wkorman@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG= 529938 

Review URL: https://codereview.chromium.org/1839533002

Cr-Commit-Position: refs/heads/master@{#383451}

[modify] https://crrev.com/043ab27b4a422d665580b12b588cba2d47afc387/third_party/WebKit/Source/core/layout/compositing/PaintLayerCompositor.cpp
[modify] https://crrev.com/043ab27b4a422d665580b12b588cba2d47afc387/third_party/WebKit/Source/core/layout/compositing/PaintLayerCompositor.h
[modify] https://crrev.com/043ab27b4a422d665580b12b588cba2d47afc387/third_party/WebKit/Source/core/paint/PaintInvalidationCapableScrollableArea.cpp
[modify] https://crrev.com/043ab27b4a422d665580b12b588cba2d47afc387/third_party/WebKit/Source/platform/graphics/paint/DisplayItem.cpp
[modify] https://crrev.com/043ab27b4a422d665580b12b588cba2d47afc387/third_party/WebKit/Source/platform/graphics/paint/DisplayItem.h

Cluster telemetry is now working also Linux Perf (5) is now green: https://build.chromium.org/p/chromium.perf/builders/Linux%20Perf%20%285%29?numbuilds=50

wkorman@: seems like your CL was the root cause of the crash. Please watch out for the problem when you try to reland your patch.

Attached is the crash stack & stdout.

Deleted: crash_stack_and_stdout.txt 371 KB

crash_stack_and_stdout.txt 371 KB View Download

Apologies and thanks for investigating and reverting for me. Filed  http://crbug.com/598358  to track re-land. Presuming I will be able to repro just by running rasterize_and_record_micro locally on Linux but let me know if otherwise.