Bug 289330 – REGRESSION (288911@main-290821@main): RegExp for large input (800KB) incorrectly returns null

• Component: JavaScriptCore
• Status: RESOLVED FIXED

[Jarred Sumner]

Created attachment 474482 [details]
it should not print null

This base64 validation RegExp
`/^(?:[A-Za-z0-9+/]{4})*(?:[A-Za-z0-9+/]{2}==|[A-Za-z0-9+/]{3}=)?$/` fails to
match valid input when the size is around 800KB. This began happening in
upstream WebKit between commits ff24546a6c0762f37c9d67c10f91aee76a868b99 and
da73ec3618fad6f43bab1cc20570898b121c9e0e.

Previously this RegExp would correctly match input of this size, but now it
returns null. 

The same pattern continues to work correctly in Node.js/V8 with inputs of this
size and in Bun v1.2.2. It regressed in Bun v1.2.3. 

The most likely cause is commit 424c8d883269 "Prevent Yarr::Interpreter's
evaluation stack from growing unboundedly" which introduced a 4MB limit on the
RegExp stack size. While this is a reasonable safety measure, it appears to be
causing valid RegExp evaluations to return different results than in
Chrome/V8/Node.js. Increasing JSC::Options::maxRegExpStackSize does workaround
the issue.

A reproduction that should run in the jsc shell is attached

Suspect Commits:
1. 424c8d883269 - "Prevent Yarr::Interpreter's evaluation stack from growing
   unboundedly" (Most likely cause)
   - Added a 4MB limit to the RegExp stack

Other relevant commits in this range:
2. d30962803be5 - "Increase Yarr matchLimit"
   - Changed match limit from 1M to 100M
3. 12c34ef5e305 - "[Yarr] Improve processing of an alternation of strings"
   - Added string list optimization (later reverted)
4. 5e5c7a9d5e4f - "Unreviewed, reverting 290791@main"
   - Reverted the string list optimization
5. 87e70c49cbfa - "Re-enable RegExp Modifiers"
6. 868302168e9b - "Implement RegExp Modifiers"
7. 80442335b668 - "[Yarr] Update YarrJIT disassembly to happen after other link
   tasks"
9. 99be77af7cd2 - "[JSC] YARR: Update UCS canonicalization tables"

[Radar WebKit Bug Importer]

<rdar://problem/146497732>

[Alexey Proskuryakov]

Thank you for the report! Could you please use canonical commit IDs, not git hashes in the future?

In case you are willing to positively identify the culprits, we store historical builds, and have tools like `Tools/Scripts/bisect-builds` and `Tools/CISupport/download-built-product`.

[Yusuke Suzuki]

Pull request: https://github.com/WebKit/WebKit/pull/42175

[EWS]

Committed 291877@main (75a5cc813c16): <https://commits.webkit.org/291877@main>

Reviewed commits have been landed. Closing PR #42175 and removing active labels.

[EWS]

Committed 289651.254@safari-7621-branch (dbe27d9378cc): <https://commits.webkit.org/289651.254@safari-7621-branch>

Reviewed commits have been landed. Closing PR #2775 and removing active labels.