New issue
Advanced search Search tips

Issue 748538 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Closed: Aug 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 1
Type: Bug



Sign in to add a comment

Stack-overflow in blink::SelectorFilterParentScope::PushParentIfNeeded

Project Member Reported by ClusterFuzz, Jul 25 2017

Issue description

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

Fuzzer: inferno_twister
Job Type: mac_asan_chrome
Platform Id: mac

Crash Type: Stack-overflow
Crash Address: 0x7fff51590ff8
Crash State:
  blink::SelectorFilterParentScope::PushParentIfNeeded
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=mac_asan_chrome&range=471987:472016

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


Issue filed automatically.

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

Comment 2 by rbyers@chromium.org, Jul 27 2017

Components: -Blink Blink>CSS
Owner: ericwilligers@chromium.org
Status: Assigned (was: Untriaged)
Looks like infinite recursion in the style resolver.  I don't see any potentially relevant blink changes in the changelog listed, but exactly one position prior to the indicated changelog there's https://chromium.googlesource.com/chromium/src/+/2319cee58d13a3ab8d876c263fc130b2405f725b which did change StyleResolver code.  Eric, any chance this was caused by your CL?

If not, then perhaps we should request a per-CL bisect?
I don't see any connection with my CL. I've asked Clusterfuzz to Redo the regression/blame.

The test case modifies the DOM from within a DOM event listener. Perhaps a SelectorFilterParentScope is still in scope when the next event is received.

Alternately, if we had memory corruption such that previous_ == this, we would have an infinite loop. We could add an assert, and make previous_ a const member to eliminate doubt. 
Labels: Update-Weekly
Status: WontFix (was: Assigned)
The PushParentIfNeeded stack overflow occurs with more than 16000 instances of SelectorFilterParentScope created by Element::RecalcStyle.

Even if Element::RecalcStyle didn't use SelectorFilterParentScope, we would have a similar stack overflow with thousands of SelectorFilterParentScope instances created by Element::RebuildLayoutTree.

Note that SelectorFilterParentScope::PushParentIfNeeded could use iteration and a heap allocated vector, instead of recursion and the stack, but stack overflows would still occur elsewhere.

Project Member

Comment 6 by ClusterFuzz, Aug 21 2017

Labels: Needs-Feedback
ClusterFuzz testcase 4867763104645120 is still reproducing on tip-of-tree build (trunk).

If this testcase was not reproducible locally or unworkable, ignore this notification and we will file another bug soon with hopefully a better and workable testcase.

Otherwise, if this is not intended to be fixed (e.g. this is an intentional crash), please add ClusterFuzz-Ignore label to prevent future bug filing with similar crash stacktrace.
Labels: ClusterFuzz-Ignore
Project Member

Comment 8 by ClusterFuzz, Sep 16 2017

ClusterFuzz has detected this issue as fixed in range 502180:502208.

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

Fuzzer: inferno_twister
Job Type: mac_asan_chrome
Platform Id: mac

Crash Type: Stack-overflow
Crash Address: 0x7fff51590ff8
Crash State:
  blink::SelectorFilterParentScope::PushParentIfNeeded
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=mac_asan_chrome&range=471987:472016
Fixed: https://clusterfuzz.com/revisions?job=mac_asan_chrome&range=502180:502208

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

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.

Sign in to add a comment