Bug 191206 – Running out of stack space not properly handled in RegExp::compile() and its callers

• Component: JavaScriptCore
• Status: RESOLVED FIXED

[Michael Saboff]

The parsing under RegExp::compile() uses recursion for nested parenthesis.  The recursive function checks for available stack space, but that error isn't properly handled by RegExp::compile() and its callers.

[Michael Saboff]

<rdar://problem/39316988>

[Michael Saboff]

Created attachment 353730 [details]
Patch

[WebKit Commit Bot]

Comment on attachment 353730 [details]
Patch

Clearing flags on attachment: 353730

Committed r237753: <https://trac.webkit.org/changeset/237753>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Ryan Haddad]

Reverted r237753 for reason:

Introduced JSC test failures

Committed r237757: <https://trac.webkit.org/changeset/237757>

[Ryan Haddad]

(In reply to Ryan Haddad from comment #5)
> Reverted r237753 for reason:
> 
> Introduced JSC test failures
> 
> Committed r237757: <https://trac.webkit.org/changeset/237757>

Failures seen here:
https://build.webkit.org/builders/Apple%20High%20Sierra%20LLINT%20CLoop%20%28BuildAndTest%29/builds/9801

[Michael Saboff]

Fixed issues with DECLARE_THROW_SCOPE placement and rolled back in patch.

Committed 237763: <https://trac.webkit.org/changeset/237763 >

[Michael Catanzaro]

Still seeing 15-20 new JSC test failures on the Linux release bots, and 6000 new failures on the debug bots.

[Michael Saboff]

(In reply to Michael Catanzaro from comment #8)
> Still seeing 15-20 new JSC test failures on the Linux release bots, and 6000
> new failures on the debug bots.

I only see that the new stress/regexp-compile-oom.js as new failures on the Linux bots, 16 variants in release and 15 in debug.  I'm going to disable the regexp-compile-oom.js on Linux since I can't debug why we can't get into the Out Of Memory situation before compiling the RegExp.

Where do you see the 6000 new failures?

[Michael Catanzaro]

That was https://build.webkit.org/builders/GTK%20Linux%2064-bit%20Debug%20%28Tests%29/builds/3879 but that was with the original version of this commit, r237757, not the corrected version r237763. So I was looking at the wrong results. Sorry, false alarm!

[Matt Lewis]

It Looks like the roll-in broke the JSC test stress/regexp-compile-oom.js.dfg-maximal-flush-validate-no-cjit on JSC release High Sierra. and about 15 failures on Debug as well:
	stress/regexp-compile-oom.js.default
	stress/regexp-compile-oom.js.dfg-eager
	stress/regexp-compile-oom.js.dfg-eager-no-cjit-validate
	stress/regexp-compile-oom.js.dfg-maximal-flush-validate-no-cjit
	stress/regexp-compile-oom.js.ftl-eager
	stress/regexp-compile-oom.js.ftl-eager-no-cjit
	stress/regexp-compile-oom.js.ftl-eager-no-cjit-b3o1
	stress/regexp-compile-oom.js.ftl-no-cjit-b3o1
	stress/regexp-compile-oom.js.ftl-no-cjit-no-inline-validate
	stress/regexp-compile-oom.js.ftl-no-cjit-no-put-stack-validate
	stress/regexp-compile-oom.js.ftl-no-cjit-small-pool
	stress/regexp-compile-oom.js.ftl-no-cjit-validate-sampling-profiler
	stress/regexp-compile-oom.js.no-cjit-validate-phases
	stress/regexp-compile-oom.js.no-ftl
	stress/regexp-compile-oom.js.no-llint


https://build.webkit.org/builders/Apple%20High%20Sierra%20Release%20JSC%20%28Tests%29/builds/6416/steps/jscore-test/logs/stdio
https://build.webkit.org/builders/Apple%20High%20Sierra%20Debug%20JSC%20%28Tests%29/builds/1687/steps/jscore-test/logs/stdio