[Webkit-unassigned] [Bug 171630] [JSC] Test stringimpl-to-jsstring-on-large-strings-2 uses a lot of RAM

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=171630

--- Comment #10 from Yusuke Suzuki <utatane.tea at gmail.com> ---
(In reply to Carlos Alberto Lopez Perez from comment #9)
> (In reply to Carlos Alberto Lopez Perez from comment #8)
> > So.. this is the issue:
> > 
> > 	 function createRegexp() {
> > 	     var s = "a".repeat(0x3fffffff);
> > 	     var r = RegExp.prototype.toString.call({
> > 		 source: s,
> > 		 flags: s,
> > 	     });
> > 	     return [s, r];
> > 	 };
> > 
> > 
> > Both Firefox and chrome abort at var s = "a".repeat(0x3fffffff); with
> > "repeat count must be less than infinity and not overflow maximum string
> > size" (firefox) or "Invalid string length".
> > 
> 
> We abort later with "Out of memory" on the call to
> RegExp.prototype.toString() which such string. But that is already late for
> this test case. We should not allow to build such string in the very fist
> place.

I'm not sure why the current behavior is undesirable.
We have an explicit limit of string length, INT32_MAX, so, the current behavior is expected.
If the length becomes larger than that limit, JSC will throw OOM error.

`"a".repeat(0x8fffffff)` => OOM error.

It seems that SpiderMonkey and V8 simply have lower limit of string length.

In the case of malicious page, even if the limit is lower, you can still easily create such a page if we retain the created strings.

var array = [];
for (var i = 0;; ++i) {
    array[i] = "a".repeat(0xffffff);
}

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20170504/c3ea72d0/attachment.html>