[Webkit-unassigned] [Bug 46746] Large files via XHR : out-of-memory crashes

[bugzilla-daemon at webkit.org]

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


Janne Koskinen <koshuin at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|DUPLICATE                   |




--- Comment #5 from Janne Koskinen <koshuin at gmail.com>  2011-01-18 05:11:50 PST ---
Re-opening. Rope fix done in Bug 43987 didn't fix the OOM issue in Symbian. It just delayed it a bit. The test case here is not the one in internal bug reporting and this test case attached here in this bug works and thats why the confusion. I'll mark this one as obsolete and attach the proper one.

Here is what is causing the OOM in symbian. Issue is amplified by the test case itself:

The one in internal bug reporting has a progress bar which queries responseText each time readyState is changed and the state is LOADING. The length of the responseText is then used to determine the progress of the download state and displayed to user "xx/100".

Now the problem. Each call to responseText allocates new JSString which is not deleted until the garbage collector is run. Meaning after few chunks into the download we run out of memory.

WebCore/bindings/js/JSXMLHttpRequestCustom.cpp
>JSValue JSXMLHttpRequest::responseText(ExecState* exec) const
>{
>    return jsOwnedStringOrNull(exec, impl()->responseText());
>}

jsOwnedStringOrNull doesn't get deleted until next collector cleanup. Quick and dirty hack would be to use jsStringOrNull instead which calls reportExtraMemoryCost and if there is not enough memory ends up reset()ting the Heap. Other alternative is to call CollectAllGarbage() each time responseText is called.

Ofc. the easiest way to deal with this is not to give user progress info ;) On a serious side the javascript code should be modified so that the progress info is changed once or twice a second to minimize memory consumption.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.