Predator and CL did not provide any possible suspects.

adding 'Blink-DOM', requesting the team to check the issue and help.

Let me take a look.

FWIW this DCHECKs:

[1:1:0120/082237.315080:FATAL:FirstLetterPseudoElement.cpp(275)] Check failed: nextLayoutObject. 
#0 0x7fa44183fb1e base::debug::StackTrace::StackTrace()
#1 0x7fa4418ad9ff logging::LogMessage::~LogMessage()
#2 0x7fa4278e5ce5 blink::FirstLetterPseudoElement::attachFirstLetterTextLayoutObjects()
#3 0x7fa4278e5be0 blink::FirstLetterPseudoElement::attachLayoutTree()
#4 0x7fa4278b6a38 blink::Element::createPseudoElementIfNeeded()
#5 0x7fa4278a6bcf blink::Element::attachLayoutTree()
#6 0x7fa427e149d7 blink::HTMLFormControlElement::attachLayoutTree()
#7 0x7fa4277cbe91 blink::ContainerNode::attachLayoutTree()
#8 0x7fa4278a6b9c blink::Element::attachLayoutTree()
#9 0x7fa4277cbe91 blink::ContainerNode::attachLayoutTree()
#10 0x7fa4278a6b9c blink::Element::attachLayoutTree()
#11 0x7fa427941b8a blink::Node::reattachLayoutTree()
#12 0x7fa4278a9904 blink::Element::rebuildLayoutTree()
#13 0x7fa4278a8ab3 blink::Element::recalcOwnStyle()
#14 0x7fa4278a81bf blink::Element::recalcStyle()
#15 0x7fa427815a4c blink::Document::updateStyle()
#16 0x7fa4278115af blink::Document::updateStyleAndLayoutTree()
#17 0x7fa427827f44 blink::Document::finishedParsing()
#18 0x7fa427f97c8a blink::HTMLConstructionSite::finishedParsing()
#19 0x7fa42801b17c blink::HTMLTreeBuilder::finished()
#20 0x7fa427fab7b9 blink::HTMLDocumentParser::end()
#21 0x7fa427fa420d blink::HTMLDocumentParser::attemptToRunDeferredScriptsAndEnd()
#22 0x7fa427fa3eeb blink::HTMLDocumentParser::prepareToStopParsing()
#23 0x7fa427fa96ae blink::HTMLDocumentParser::processTokenizedChunkFromBackgroundParser()
#24 0x7fa427fa5c76 blink::HTMLDocumentParser::pumpPendingSpeculations()
#25 0x7fa427fa53c5 blink::HTMLDocumentParser::resumeParsingAfterYield()
#26 0x7fa427fd352d blink::HTMLParserScheduler::continueParsing()

Here's a hand-minimized repro. This seems to be about ::first-letter rules in inline-flex fieldsets.

Deleted: fuzz-49.html 231 bytes

fuzz-49.html 231 bytes View Download

Debugged this a bit. The problem is during reattach the first-letter pseudo element doesn't find its next layout object, the text renderer for "A".

Dan, Elliot, how is this supposed to work?

The regression range is likely because "Unprefix the CSS 'filter' property" and the test contains the 'filter' property. +fs if he has any insights on 'filter'.

I think there are two possible problems:

1. At the point of the failure, the layout tree looks weird.
fieldset
  p
    anonymous
      x-test
    anonymous
      <<pseudo:first-letter>>
    anonymous
      x-test

FirstLetterPseudoElement::firstLetterTextLayoutObject() assumes the <<pseudo>> is the first child. Someone breaking the assumption, or FirstLetterPseudoElement should not assume that and look for other siblings. I'm not sure which it is atm.

2. 'filter' on '::first-letter'?

Looking at the spec "Styling the ::first-letter Pseudo-element"
https://www.w3.org/TR/css-pseudo-4/#first-letter-pseudo

I think we shouldn't apply 'filter' or any properties that create layers to '::first-letter'.

#2 may mitigate problems in ::first-letter, but the root cause is likely #1.

+cbiesinger as this looks more like Flexbox now.

Applying http://crrev.com/2373963002 to HTMLFieldSetElement::createLayoutObject() seems to fix the problem.

But I guess, this problem isn't limited to HTMLFieldSetElement. An alternative fix is not to create pseudo if |parentStyle.isDisplayFlexibleOrGridBox()|, in which case we change display to |equivalentBlockDisplay()| in StyleAdjuster.

WIP: http://crrev.com/2650583003

I can't explain why 'filter' is needed to reproduce yet.

So if "Unprefix the CSS 'filter' property" triggered it, then maybe redo the bisect with s/filter/-webkit-filter/. I don't know why 'filter' triggers is though - does some other layer-creating property (like clip-path, maybe "clip-path: inset(0px)") trigger it too?

> does some other layer-creating property (like clip-path, maybe "clip-path: inset(0px)") trigger it too?

You're right, "z-index: 100" also triggers, so the criteria is:
a. An element that does not create LayoutFlexibleBox for "display: inline-flex"
b. and that element creates layer or stacking context
c. and ::first-letter.

I don't understand why LayoutFlexibleBox is ok yet, it doesn't create anonymous boxes.

Can TE do bisect using this attached file?

Deleted: f-firstletter-675117.html 225 bytes

f-firstletter-675117.html 225 bytes View Download

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

commit 880301a7e70e48fd5eb46dc441f3d974ec4ae6bf
Author: kojii <kojii@chromium.org>
Date: Thu Jan 26 09:54:16 2017

Fix ::first-letter not to apply non-block containers

The CSS Pseudo-Elements[1] defines that ::first-line and ::first-letter
only applies to block containers.

Checking |isLayoutBlockFlow()| works in most cases. However, when
|Element::createLayoutObject()| creates |LayoutObject| without using
|LayoutObject::createObject()|, |isLayoutBlockFlow()| may conflict with
the CSS display property. An example is to apply 'display: flex' to
<fieldset> elements.

This patch changes to check both |isLayoutBlockFlow()| and the CSS
display property. The list of values of the 'display' property to be
block containers is defined in CSS Display[2].

[1] https://drafts.csswg.org/css-pseudo-4/
[2] https://drafts.csswg.org/css-display/

BUG= 675117 

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

[add] https://crrev.com/880301a7e70e48fd5eb46dc441f3d974ec4ae6bf/third_party/WebKit/LayoutTests/fast/css/first-letter-to-non-block-container-expected.html
[add] https://crrev.com/880301a7e70e48fd5eb46dc441f3d974ec4ae6bf/third_party/WebKit/LayoutTests/fast/css/first-letter-to-non-block-container.html
[modify] https://crrev.com/880301a7e70e48fd5eb46dc441f3d974ec4ae6bf/third_party/WebKit/Source/core/layout/LayoutObject.h
[modify] https://crrev.com/880301a7e70e48fd5eb46dc441f3d974ec4ae6bf/third_party/WebKit/Source/core/style/ComputedStyle.h

ClusterFuzz has detected this issue as fixed in range 446231:446318.

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

Fuzzer: inferno_twister
Job Type: linux_asan_chrome_media
Platform Id: linux

Crash Type: UNKNOWN READ
Crash Address: 0x000000000000
Crash State:
  blink::FirstLetterPseudoElement::attachFirstLetterTextLayoutObjects
  blink::Element::createPseudoElementIfNeeded
  blink::Element::attachLayoutTree
  
Sanitizer: address (ASAN)

Regressed: https://cluster-fuzz.appspot.com/revisions?job=linux_asan_chrome_media&range=400746:400775
Fixed: https://cluster-fuzz.appspot.com/revisions?job=linux_asan_chrome_media&range=446231:446318

Minimized Testcase (1.18 Kb): https://cluster-fuzz.appspot.com/download/AMIfv94f8mcAs8UV2SOE8TVvTYq6F-2wCpgF5iZ_IDlqdBNZTJFVN8kdNQvMWDkM_Tb8MXQhHowhPRbrl7XMYFiztYvWR9GqqkwBtTwDXtUNxQlUFOJSw_yViZzFGOz-e7aqwWVeSnZGaVzdZs2Tv5gAQPub5tXTbQ?testcase_id=5141670313328640

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.

 Issue 675073  has been merged into this issue.