rev range maybe https://chromium.googlesource.com/chromium/src/+log/42f33c141cbe3f2ad0e6ec038bf78404e22c7bb3..6f247be8198a5ebcbd66d20eb6fb170d6d31b0a6?pretty=fuller&n=1000

skobes can you take a look at this issue?

cc kojii because of  issue 613869  and  issue 568744 

It looks like FloatingObjects::m_placedFloatsTree contains a stale LayoutObject pointer?  I don't think my changes in the range are related.

I tried to repro with go/clusterfuzz-repro, but without success.  The script printed:

Starting run number: 0
Starting run number: 1
Starting run number: 2
Starting run number: 3
Starting run number: 4
Starting run number: 5
Starting run number: 6
Starting run number: 7
Starting run number: 8
Starting run number: 9
Starting run number: 10
Starting run number: 11
Starting run number: 12
Starting run number: 13
Starting run number: 14
Starting run number: 15
Starting run number: 16
Starting run number: 17
Starting run number: 18
Starting run number: 19
Starting run number: 20
Starting run number: 21
Starting run number: 22
Starting run number: 23
Starting run number: 24
No crash found.
XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server ":1"
      after 448 requests (447 known processed) with 0 events remaining.
blackbox: no process found

I'm not sure if this means the bug is not reproducible, or if there was a problem with the Clusterfuzz script.

This has layoutOrthogonalWritingModeRoots() in stack, I can try.

I can reproduce this once every 2-3 runs by setting ASAN_OPTIONS as specified.

This looks like  issue 604095  coming back, in worse severity. It was assertion failure only, and it somehow stopped reproducing and closed.

It looks like there's a case where floats were not removed from its containing block when dirtied. In normal layout, it is still cleared when the parent layouts, but in orthogonal flow, since we layout the child first, the safe guard doesn't kick in and the parent keeps deleted float object.

The WIP patch[1] that clears floating objects in orthogonal flow seems to fix this case, I can run 10 times with it applied. But the fix was once disliked because the reviewer wants to fix where floating objects were not removed rather than having the safe guard in orthogonal flow layout, and I could not identify where it is after spending 2 weeks.

So probably a safe fix exists, which slows down only cb of orthogonal flows has floats. Tough to figure out why it's not removed.

robhogan@, are you still not comfortable to clear floats as a safe guard?

[1] PS1 of https://codereview.chromium.org/2025543002

Probably related with  issue 633409 . Floats were often moved, thought  issue 642028  may have fixed it but didn't, so where it's not removed is still not identified.

LayoutObject::destroy() calls removeFloatingOrPositionedChildFromBlockLists(), but there are no ancestors that has the object in floats, and thus removeFloatingObject() doesn't remove. Probably at that point the object was moved, but the move didn't update FloatingObjects probably because it will be re-created during layout, but I haven't identified how that works yet.

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

commit 5c43382692e6b687373576984181e52c30ccd142
Author: kojii <kojii@chromium.org>
Date: Sat Sep 17 19:39:59 2016

Fix when orthogonal writing mode roots have floating siblings

When orthogonal writing mode roots have floating siblings, its
containing block may still have old or even deleted LayoutObjects.
This occurs when LayoutMultiColumnFlowThread::populate(),
LayoutBoxModelObject::moveChildrenTo() with !fullRemoveInsert,
or more, for the optimization purposes.

This patch clears such objects to be re-created when the containing
block is laid out.

BUG= 604095 ,  633409 ,  646178 

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

[add] https://crrev.com/5c43382692e6b687373576984181e52c30ccd142/third_party/WebKit/LayoutTests/fast/writing-mode/orthogonal-writing-modes-floats-crash-expected.txt
[add] https://crrev.com/5c43382692e6b687373576984181e52c30ccd142/third_party/WebKit/LayoutTests/fast/writing-mode/orthogonal-writing-modes-floats-crash.html
[modify] https://crrev.com/5c43382692e6b687373576984181e52c30ccd142/third_party/WebKit/Source/core/frame/FrameView.cpp

ClusterFuzz has detected this issue as fixed in range 419371:419385.

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

Fuzzer: bj_broddelwerk
Job Type: linux_asan_chrome_v8_arm
Platform Id: linux

Crash Type: Heap-use-after-free READ 4
Crash Address: 0xba50950c
Crash State:
  blink::ShapeOutsideInfo::isEnabledFor
  blink::LayoutBox::shapeOutsideInfo
  blink::ComputeFloatOffsetForLineLayoutAdapter<
  
Recommended Security Severity: High

Regressed: https://cluster-fuzz.appspot.com/revisions?job=linux_asan_chrome_v8_arm&range=353966:353986
Fixed: https://cluster-fuzz.appspot.com/revisions?job=linux_asan_chrome_v8_arm&range=419371:419385

Minimized Testcase (0.79 Kb): https://cluster-fuzz.appspot.com/download/AMIfv95cBQPvGfzGPf2I-YIhM78OHMwZpRPAnACnkkIX1T4GXxcTbXL4OTWnJN7O6OodMMyso7ePRf-rtjzAjrERv6DiUanSA9OYy8AYw_Mcu_MIzfLwVOZVL1T_8IWEnjqqe_fR9UqNp0GEHCkwykCnsXmn5h8a4Q?testcase_id=5543844689215488

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.

ClusterFuzz testcase is verified as fixed, closing issue.

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

Your change meets the bar and is auto-approved for M54 (branch: 2840)

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

commit f0a010e317a1043e7faf7160f6d2afb760d6f1f5
Author: Koji Ishii <kojii@chromium.org>
Date: Tue Sep 20 13:11:28 2016

Merge 2840: Fix when orthogonal writing mode roots have floating siblings

When orthogonal writing mode roots have floating siblings, its
containing block may still have old or even deleted LayoutObjects.
This occurs when LayoutMultiColumnFlowThread::populate(),
LayoutBoxModelObject::moveChildrenTo() with !fullRemoveInsert,
or more, for the optimization purposes.

This patch clears such objects to be re-created when the containing
block is laid out.

BUG= 604095 ,  633409 ,  646178 

Review-Url: https://codereview.chromium.org/2025543002
Cr-Commit-Position: refs/heads/master@{#419376}
(cherry picked from commit 5c43382692e6b687373576984181e52c30ccd142)

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

Cr-Commit-Position: refs/branch-heads/2840@{#436}
Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607}

[add] https://crrev.com/f0a010e317a1043e7faf7160f6d2afb760d6f1f5/third_party/WebKit/LayoutTests/fast/writing-mode/orthogonal-writing-modes-floats-crash-expected.txt
[add] https://crrev.com/f0a010e317a1043e7faf7160f6d2afb760d6f1f5/third_party/WebKit/LayoutTests/fast/writing-mode/orthogonal-writing-modes-floats-crash.html
[modify] https://crrev.com/f0a010e317a1043e7faf7160f6d2afb760d6f1f5/third_party/WebKit/Source/core/frame/FrameView.cpp

Over 48 hours in Beta, requesting merge to Stable.

[Automated comment] Request affecting a post-stable build (M53), manual review required.

Approving merge to M53 branch 2785 based on comment #18. Please merge ASAP. Thank you.

Please hold off M53 merge for now. kerz@ or I will update the bug if merge is needed. Thank you.

This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible!

If all merges have been completed, please remove any remaining Merge-Approved labels from this issue.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

We decided NOT to take this merge in for M53 respin this week. 

Issue 648371 has been merged into this issue.

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

commit f0a010e317a1043e7faf7160f6d2afb760d6f1f5
Author: Koji Ishii <kojii@chromium.org>
Date: Tue Sep 20 13:11:28 2016

Merge 2840: Fix when orthogonal writing mode roots have floating siblings

When orthogonal writing mode roots have floating siblings, its
containing block may still have old or even deleted LayoutObjects.
This occurs when LayoutMultiColumnFlowThread::populate(),
LayoutBoxModelObject::moveChildrenTo() with !fullRemoveInsert,
or more, for the optimization purposes.

This patch clears such objects to be re-created when the containing
block is laid out.

BUG= 604095 ,  633409 ,  646178 

Review-Url: https://codereview.chromium.org/2025543002
Cr-Commit-Position: refs/heads/master@{#419376}
(cherry picked from commit 5c43382692e6b687373576984181e52c30ccd142)

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

Cr-Commit-Position: refs/branch-heads/2840@{#436}
Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607}

[add] https://crrev.com/f0a010e317a1043e7faf7160f6d2afb760d6f1f5/third_party/WebKit/LayoutTests/fast/writing-mode/orthogonal-writing-modes-floats-crash-expected.txt
[add] https://crrev.com/f0a010e317a1043e7faf7160f6d2afb760d6f1f5/third_party/WebKit/LayoutTests/fast/writing-mode/orthogonal-writing-modes-floats-crash.html
[modify] https://crrev.com/f0a010e317a1043e7faf7160f6d2afb760d6f1f5/third_party/WebKit/Source/core/frame/FrameView.cpp

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot