rune@ this looks like its in code you are familiar with.

Not able to reproduce this with a non-asan build. Started an asan build.

Looking at the code, it looks like we are doing a sync style recalc from RootScrollerController::RecomputeEffectiveRootScroller() at a point where we are in the process of removing all children of Document from ImplicitClose(). The document element is removed from Document, but Document::document_element_ is still points to it. Since it's a traced member it should still be valid I guess ...

My analysis in https://bugs.chromium.org/p/chromium/issues/detail?id=757585#c3 was right. I was able to reproduce in a normal build, did not need asan. The problem was that --run-layout-tests is required to trigger the issue.

I did not see the IsHTMLHtmlElement() crash though, and the document_element_ points to a valid object. What's causing problems is that as I mentioned documentElement() is removed from the tree and we have a null parent. The style recalc code expects the parent of documentElement() to be non-null.

I think the sync UpdateStyle() caused by RecomputeEffectiveRootScroller() is the root cause here. We should not allow style update in the middle of a DOM operation.

bokan@: Could we postpone RecomputeEffectiveRootScroller() until the lifecycle update for the next frame?

Yeah, it probably makes sense to reset to the document node and only recalculate the effective from the end of a layout. I'll land a fix. Thanks for the analysis!

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

commit a9e0a0c43a8f9373f22f860a0615a69f55c91afa
Author: David Bokan <bokan@chromium.org>
Date: Thu Aug 24 20:37:03 2017

Don't recompute rootScroller on removal

Since RecomputeRootScroller needs to synchronously update style and
layout, DOM mutation is a bad time to make that call and can cause the
attached crash. Instead, we should just reset the effective to the
document Node which is the default and always valid.

Bug:  757585 
Change-Id: I72ef68805d02db1b4c8a25d4f17748bdf629df55
Reviewed-on: https://chromium-review.googlesource.com/629577
Commit-Queue: David Bokan <bokan@chromium.org>
Reviewed-by: Rune Lillesveen <rune@opera.com>
Cr-Commit-Position: refs/heads/master@{#497177}
[add] https://crrev.com/a9e0a0c43a8f9373f22f860a0615a69f55c91afa/third_party/WebKit/LayoutTests/fast/rootscroller/remove-rootscroller-crash.html
[modify] https://crrev.com/a9e0a0c43a8f9373f22f860a0615a69f55c91afa/third_party/WebKit/Source/core/page/scrolling/RootScrollerController.cpp

ClusterFuzz has detected this issue as fixed in range 497168:497199.

Detailed report: https://clusterfuzz.com/testcase?key=6736106912743424

Fuzzer: mbarbella_js_mutation_layout
Job Type: linux_asan_content_shell_drt
Platform Id: linux

Crash Type: Null-dereference READ
Crash Address: 0x000000000040
Crash State:
  blink::Document::PropagateStyleToViewport
  blink::Document::UpdateStyle
  blink::Document::UpdateStyleAndLayoutTree
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=linux_asan_content_shell_drt&range=493344:493365
Fixed: https://clusterfuzz.com/revisions?job=linux_asan_content_shell_drt&range=497168:497199

Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=6736106912743424

See https://github.com/google/clusterfuzz-tools for more information.

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

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

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