[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 #11 from Carlos Alberto Lopez Perez <clopez at igalia.com> ---
(In reply to Yusuke Suzuki from comment #10)
> (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);
> }


Here is a test for that:

https://people.igalia.com/clopez/wkbug/largestrings/large-array-alive.html

This is what I observer:

 * Chrome: there isn't any noticiable spike of RAM by clicking any of the buttons. You end getting and "Aw! snap" error page.. that is.. the webview is killed but without spiking in RAM usage. The user's running session will be fine.

 * Firefox: The worse situation by clicking any of the buttons is a speak of RAM around +3-4GB. Then it throws an "undefined" javascript exception. There is no crash of the webview. The user's running session will be fine if the computer can handle a spike of +3GB of RAM.

 * Safari/WebKitGTK+: It will use all your RAM and cause an OOM situation that can potentially crash not only the webview, but also the user's running session. I have to say that MacOS seems to deal much better with this. On Linux OOM situations like this usually cause the desktop to freeze for several minutes, which is a PITA.

-- 
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/8b4b4517/attachment.html>