User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:35.0) Gecko/20100101 Firefox/35.0 Build ID: 20150125221831 Steps to reproduce: Version: JavaScript-C31.2.0esr try { a= new Array( ) ; while ( 1 ) a= new Array( a) ; } catch ( e) { } Actual results: Infinite loop with increasing memory; consumes all memory Expected results: Throw "out of memory" or "InternalError: allocation size overflow" Spidermonkey 1.8.5 throws out of error exception doesn't go into infinite loop and thereby doesnt consume all memory. All the newer versions fail to handle this and consumes all memory

Spidermonkey 1.8.5 (introduced in Firefox 4.0) is not supported anymore. Please use latest one which is SpiderMonkey 31 https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/Releases

The mention of 1.8.5 confuses things a bit, but this was actually filed on v31. Spandan, what behavior do you see on mozilla-central? Terrence, what do you think should happen here?

This is observed on 31.

Emanuel, Spidermonkey 31.2 goes into infinite loop consuming all memory. Sorry for confusion. I have executed this code in all versions and observed that, it is well handled in older version 1.8.5.

Looks like our GC triggers are not handling this case well, I'll take a look Tuesday.

Thanks. Spandan, 31 and mozilla-central are not the same thing (mozilla-central is already on 38!). If possible you should apply your fuzzer to the latest code, since it is much more likely to receive fixes that aren't widespread crashes or exploits (and being pre-production code, it's also more likely to contain bad bugs). Look at [1] for instructions on how to get the latest tree. mozilla-central contains all of Gecko in addition to SpiderMonkey, so it's a big repository, but the latest SM code isn't available separately. mozilla-central is updated regularly; it's what the Firefox Nightlies are based on. [1] https://developer.mozilla.org/en-US/docs/Simple_Firefox_build

Emanuel, I have mentioned 31 as SpiderMonkey version. Which I have downloaded from https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/Releases/31 I will test this on Mozilla central and let you know. Thanks.

Emanuel and Terrence, I have tested on latest mozilla-central revision "a7c177546ca0". Able to reproduce the bug.

Verified. In the shell, this OOMs correctly when the heap size passes 4GiB. In the browser, the heap size grows up to 10GiB, then the script stops, but the memory does not go away. Triggering memory manually via about:memory does not release the memory either.

I'm making this summary more specific. Adjust as desired.

I had some trouble tracking this down with e10s, so all of these notes are without it enabled. I did not get the slow script dialog there, among other weirdnesses, so this needs more investigation in that context. For non-e10s, we're absolutely returning an OOM exception, propagating that up to nsXPCWrappedJSClass::CheckForException, which sets it and calls JS_ReportPendingException, which ends up in SystemErrorReporter. Unfortunately, we appear not to have a ScriptContext(?), so we end up reporting in the PrivilegedJunkScope and not calling any of the useful error reporters, per the comment in SystemErrorReporter. Of course, the OOM exception has nothing to do with the liveness of the objects on the window. The script stopped executing when we raised the OOM, but the objects are all still reachable via |window.a|, so I don't think the "infinite" memory usage is a bug, as such. So I guess the bug is actually in how XPConnect is running the script and reporting errors from it.

> So I guess the bug is actually in how XPConnect is running the script How exactly did you run the script?

(In reply to Boris Zbarsky [:bz] from comment #12) > > So I guess the bug is actually in how XPConnect is running the script > > How exactly did you run the script? Good question! Given that the behavior did not manifest in the shell, I embedded it in this trivial HTML and ran it in the browser.

Any update on this bug?

Its been more than 6 months, there is no update on this. Writing this small code will crash entire machine, potentially leads to Denial of service. I could still replicate on latest builds.

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.