Find it and CL did not provide any possible suspects.
Using Code Search for the file, "paintlayerscrollablearea.cpp" assigning to the concern owner.

Suspecting Commit#
https://chromium.googlesource.com/chromium/src/+/c302a98ceb085bf25d0c004e666d64fd4c3ee9f6

@yigu -- Could you please look into the isue, kindly re-assign if this is not related to your changes.
Thank You.

@flackr Could you please take a look at the sticky position related crash? Thanks.

I can't reproduce this on linux, linux asan or windows non asan and I seem to be missing clang_rt.asan_dynamic-i386.dll to produce a windows asan build. Is the regression range for sure? There's nothing obvious from that range.

It seems that we must have a stale m_ancestorOverflowLayer on the PaintLayer and we try to call rareData() on it at https://chromium.googlesource.com/chromium/src/+/4364c7ba2ff5c2a3af54212eb7c756cc3a06afa7/third_party/WebKit/Source/core/paint/PaintLayerScrollableArea.cpp#1494 due to a layout.

I'm still trying to come up with a way that this could happen, given that any time a PaintLayer is removed we unset all descendant m_ancestorOverflowLayer pointers that point above the removed layer (i.e. to its m_ancestorOverflowLayer) and anytime we add a child we have a DCHECK that it does not have an ancestor overflow layer - though perhaps this should be a release check to get better coverage.

Issue 678452 has been merged into this issue.

If this update was incorrect, please add "Fracas-Wrong" label to prevent future updates.

- Go/Fracas

Users experienced this crash on the following builds:

Win Canary 57.0.2977.0 -  0.41 CPM, 3 reports, 3 clients (signature blink::PaintLayerScrollableArea::invalidateAllStickyConstraints)

If this update was incorrect, please add "Fracas-Wrong" label to prevent future updates.

- Go/Fracas

If you see go/chromecrash (https://goto.google.com/kjuhe) this doesn't seems to be a recent regression and is existing from M54.

Thank you!

Is there any update on this? I'm hitting this on my canary really frequently (crash/c0b1253080000000, crash/bceddda580000000) and I literally will have to give up on canary until this is fixed.

Also, this is not Windows only as I'm hitting on osx sierra.

re #9, If you have any advice for how to hit this crash it would be very helpful. I have been unable to reproduce it so far. Are there particular sites that seem to crash? Does it crash regularly in incognito (i.e. with no extensions loaded)?

This crash has been around for a long time but very infrequent, however there was a recent uptick (at least on Mac) around https://crrev.com/9d96126f67850daf3c07586dc09fa334d592529c which changes layout behavior immediately before the crashing call to invalidate sticky constraints. This could have caused us to crash more frequently.

I just visit https://www.gumtree.com/search?search_category=all&q=hd500x&tq=%7B%22i%22%3A%22hd5%22%2C%22s%22%3A%22hd5%22%2C%22p%22%3A0%2C%22t%22%3A15%7D&search_location=  
(or do a search on that page)
maybe is due to some ads?

 Issue 679199  has been merged into this issue.

Hmm, I can't reproduce on tip of tree (59.0.2984.0) or on canary (57.0.2978.0) on my Mac Desktop. I've also tried canary 57.0.2983.0 on a macbook pro retina. Have you tried this in an incognito window? Do you have any non-default flags turned on?

I wonder if it's specific to ads being served to you if saving the page in stable would cause the crash when loaded in canary? Maybe this would give us a reliable repro.

I'm observing the same crash on OSX 10.12.2 (16C67) using the latest Canary (57.0.2983.0). This also reproduces in incognito mode.

I can only reproduce this with my ad blocker disabled or with google.com whitelisted so this might be ad related.

Saving the page in stable and opening it in canary doesn't reproduce the crash for me.

Crash IDs:
Crash ID 6a122464-725a-478f-b229-70f953c97b27 (Server ID: e487717a80000000)
Crash ID eb5ecb40-f529-4291-8bb7-460671dd07bd (Server ID: ba1e797080000000)
Crash ID Crash ID d7800672-a357-4ddf-acfa-9ecb597d9ee5 (might be the incognito crash)

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

commit 36f7d1fc579ca461cb46cefb3f5598139056c681
Author: flackr <flackr@chromium.org>
Date: Wed Jan 18 00:39:32 2017

Make having an existing ancestor overflow layer when adding a PaintLayer fatal.

When a PaintLayer is added it should not have an existing ancestor overflow
layer as it could be at best incorrect, and at worst point to a PaintLayer which
has / will be deleted without notifying the layer. This check used to be debug
only but we are seeing a crash likely due to an invalid ancestor overflow layer
so adding this check should help find the code path where it is added.

BUG= 679170 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2

Review-Url: https://codereview.chromium.org/2631193002
Cr-Commit-Position: refs/heads/master@{#444207}

[modify] https://crrev.com/36f7d1fc579ca461cb46cefb3f5598139056c681/third_party/WebKit/Source/core/paint/PaintLayer.cpp

Aha, this crash only happens with experimental-web-platform-features enabled. Investigating.

I found the cause of this crash and have a fix up at https://codereview.chromium.org/2644633003/. Details are in the code review.

 Issue 678395  has been merged into this issue.

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

commit a10ba600a7ad192660ded5dbe0ef94a559724452
Author: flackr <flackr@chromium.org>
Date: Thu Jan 19 19:59:37 2017

ancestorOverflowLayer should not cross frame boundaries.

First off, we don't want sticky on the document to have any effect. Secondly,
there seems to be no chain from the child frame's root PaintLayer to the parent
which means that we do not correctly clean up ancestorOverflowLayers when
layers in the parent are removed.

BUG= 679170 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2

Review-Url: https://codereview.chromium.org/2644633003
Cr-Commit-Position: refs/heads/master@{#444824}

[modify] https://crrev.com/a10ba600a7ad192660ded5dbe0ef94a559724452/third_party/WebKit/Source/core/paint/PrePaintTreeWalk.cpp

ClusterFuzz testcase 6037737645015040 is verified as fixed, so closing issue.

If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue.

ClusterFuzz has detected this issue as fixed in range 444720:444724.

Detailed report: https://cluster-fuzz.appspot.com/testcase?key=6496811411046400

Fuzzer: mbarbella_js_mutation_layout
Job Type: windows_syzyasan_content_shell
Platform Id: windows

Crash Type: UNKNOWN
Crash Address: 0x000000bb
Crash State:
  blink::PaintLayerScrollableArea::invalidateAllStickyConstraints
  blink::LayoutBoxModelObject::invalidateStickyConstraints
  blink::LayoutBlock::updateAfterLayout
  
Memory Tool: SYZYASAN

Regressed: https://cluster-fuzz.appspot.com/revisions?job=windows_syzyasan_content_shell&range=441510:441524
Fixed: https://cluster-fuzz.appspot.com/revisions?job=windows_syzyasan_content_shell&range=444720:444724

Minimized Testcase (0.78 Kb): https://cluster-fuzz.appspot.com/download/AMIfv95pZEdyQPBESY2TcKcrXDP_DRB43kLxcwn4a1y9iUZNuCn9S_MNItWRN9Cbx4X-fmEAmaTXAZ9JL0_EB4Z9tFbO7SRv2Ttae5XIrn1zZNTlQj2P5AeJ4-al0phk92UC8d2M1rA9HuyWQAWKT14Dl-oTGiyeFwbOpykIf71-5YjNPAii2usZAzxadUCop7KAcdXptcpL8NwMuWPoU4cASb3omTFm-PZqysmvqyfKer0D4ROMR1u_IuLj1Azh4sESLwQHbF6k_zuLh3KjADL4nxtwCEAdCYxR-2wxF4cPMjlQ5uNJmls7ZEJc6X55Ogz50Vh18YnaEQUP-gsHTHnQJhhyXUBuqu4TW537-LoAIuu199XifBEa3yXnnu8KnwXkDNCAc5sBqSXqb8zC_20NwdUltstnCw?testcase_id=6496811411046400

See https://dev.chromium.org/Home/chromium-security/bugs/reproducing-clusterfuzz-bugs for more information.

If you suspect that the result above is incorrect, try re-doing that job on the test case report page.