Glob filter `*-*-*-*-*-*-*x` takes ~6 s per item against an 80-dash line (56 s with one more `*-`): glob matching is exponential and, unlike regex, has no timeout

[matt-edmondson]

What's wrong

IsGlobMatch (TextFilter/TextFilter.cs ~line 415 at c4eec7b) hands every text token to DotNet.Glob's glob.IsMatch. It is called from DoesMatchGlob for the excluded, optional and required tokens (~lines 341, 352, 363). DotNet.Glob backtracks recursively over *, so a pattern with several *s that fails near the end costs exponential time in the number of *s.

The regex path is protected by RegexMatchTimeout (~line 124), so that "a caller-supplied pattern cannot hang the calling thread". The glob path has no equivalent limit.

Reproduction (observed on net10.0, default ByWordAny)

TextFilter.IsMatch(new string('-', 80), pattern, TextFilterType.Glob):

pattern	result	time
*-*-*-*-*-*x	false	825 ms
*-*-*-*-*-*-*x	false	5,909 ms
*-*-*-*-*-*-*-*x	false	55,733 ms

Against a token of 40 as, the pattern "*a"×10 + "*b" took 12,071 ms, and ×12 took 84,563 ms.

Expected: a few milliseconds. A wildcard match with only * and ? can run in O(n·m), or linear with the standard two-pointer star-backtrack.

Why it matters

An 80-dash line is an ordinary markdown or log separator. Filter() pays this cost for every item and every word, typically on the UI thread and on every keystroke as the user types. A filter box over log lines can freeze the app for minutes from a pattern a user could plausibly type.

Suggested fix / acceptance criteria

• Collapse consecutive *s, and evaluate globs with a non-recursive wildcard matcher (two-pointer, backtracking only to the last *). Alternatively, translate the glob to a Regex compiled with RegexOptions.NonBacktracking, or with the existing RegexMatchTimeout.
• The patterns above against an 80-character dash token complete in well under 100 ms.
• Existing glob semantics are unchanged: case sensitivity, character classes, and slashes matched as ordinary characters (Glob * and ? never match across / or \, so any item containing a slash is filtered out #114).

[matt-edmondson]

Triage

• Category: Bug (performance / denial of service)
• Priority: High. A pattern a user could plausibly type, such as a markdown or log separator, freezes Filter() for seconds to minutes. It usually runs on the UI thread on every keystroke, and nothing bounds it the way RegexMatchTimeout bounds the regex path.
• Area / suggested assignee: TextFilter glob matching (IsGlobMatch / DoesMatchGlob). Suggest @matt-edmondson as the repository maintainer.
• Duplicates: None. It is related to Regex timeout applies per word per item, so one catastrophic-backtracking pattern still freezes Filter() for N seconds (10 items: 10 s) #118 (regex timeout applies per word per item), which is the regex-side counterpart. A fix here should not repeat that per-word budget problem.
• In progress: No open PR covers this.
• Notes: The acceptance criteria are concrete. The recommended fix is a two-pointer wildcard matcher that collapses runs of *. Keep the Glob * and ? never match across / or \, so any item containing a slash is filtered out #114 slash semantics, and coordinate with Glob **/ patterns match nothing since the #114 separator fix: src/**/*.cs and **/*.cs filter out every path #126 and Glob filter 1/2 also matches 1\2, and excluding -*/* also hides C:\temp: / and \ are masked to the same character #132, which touch the same masking code.

---

Generated by Claude Code