Unable to find the suspect through code search and also from the provided CL, hence cc'ing to @shend who have worked on similar  issue 770482 .

shend@ Could you please take a look in to this issue?

Thanks2

Seems like a performance issue or infinite loop with :matches() causing the fuzzer to timeout (the test case uses matches and the matches CL is in the regression range).

Assigning to ericwilligers. This may just be a Wont-Fix if there's nothing wrong with the code.

I loaded the test case's style sheet in an ASAN Chromium and did not observe any crash.

How do I reproduce the timeout?

Most of the :matches() in the test case are not valid; they should be rejected quickly, without causing much computation.

> Most of the :matches() in the test case are not valid;

I was mistaken. The test case contains '-' characters, but these are valid in tag names.



The following example times out in ASAN builds.

:matches(j, k, l, m, n, o)
:matches(j, k, l, m, n, o)
:matches(j, k, l, m, n, o)
:matches(j, k, l, m, n, o) {}

:matches(j, k, l, m, n, o)
:matches(j, k, l, m, n, o)
:matches(j, k, l, m, n, o)
:matches(j, k, l, m, n, o) {}

:matches(j, k, l, m, n, o)
:matches(j, k, l, m, n, o)
:matches(j, k, l, m, n, o)
:matches(j, k, l, m, n, o) {}

:matches(j, k, l, m, n, o)
:matches(j, k, l, m, n, o)
:matches(j, k, l, m, n, o)
:matches(j, k, l, m, n, o) {}

We could reduce the limit in CSSSelectorList::ExpandedFirstMatchesPseudo() to prevent such complex cases from expanding, but the code is working as intended.

ClusterFuzz testcase 4667660231770112 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.