The following testcase crashes on mozilla-central revision 556b9cfb269f (run with --ion-eager): gcparam("maxBytes", gcparam("gcBytes") + 4*1024); evaluate("\ function g(a) {\ a();\ }\ function f(y) {\ for (var i = 0; i < 7; ++i) {\ q = function() { f(y); };\ }\ g(q);\ }\ for (var i = 0; i < 5; ++i)\ f(i);\ ");

Valgrind trace: ==6544== Invalid read of size 4 ==6544== at 0x820F37A: js::ContextStack::popInvokeArgs(js::InvokeArgsGuard const&) (Stack.cpp:548) ==6544== by 0x80FBFFC: js::Invoke(JSContext*, JS::Value const&, JS::Value const&, unsigned int, JS::Value*, JS::Value*) (Stack.h:1647) ==6544== by 0x83C27AC: js::ion::InvokeFunction(JSContext*, JSFunction*, unsigned int, JS::Value*, JS::Value*) (VMFunctions.cpp:63) ==6544== by 0x55389A5: ??? ==6544== Address 0xfed7fa8c is just below the stack ptr. To suppress, use: --workaround-gcc296-bugs=yes ==6544== ==6544== Invalid read of size 4 ==6544== at 0x820F37A: js::ContextStack::popInvokeArgs(js::InvokeArgsGuard const&) (Stack.cpp:548) ==6544== by 0x833D5E1: js::ion::ThunkToInterpreter(JS::Value*) (Stack.h:1647) ==6544== by 0x55384F3: ??? ==6544== by 0x833DBD4: EnterIon(JSContext*, js::StackFrame*, void*) (Ion.cpp:1426) ==6544== by 0x80FB376: js::RunScript(JSContext*, JS::Handle<JSScript*>, js::StackFrame*) (jsinterp.cpp:301) ==6544== Address 0x8 is not stack'd, malloc'd or (recently) free'd The test only works on an opt-build (build options --disable-debug --enable-optimize --enable-valgrind --target=i686-pc-linux-gnu --enable-gczeal). S-s because of the first invalid read which might be dangerous.

This might be a duplicate of Bug 800862.

Assigning to nbp to see if it is actually a dupe, whenever that other bug is figured out, or whatever.

Marking sec-critical trusting similarity to bug 800862 and the same rating there.

Nicolas has a patch for bug 800862, hopefully we can figure out dupe status soon.

I cannot reproduces this on m-c. Valgrind is extremely verbose but it does not contain any reference to popInvokeArgs. Can somebody else who can reproduce this bug check with the patch from Bug 800862. Remove my-self from the assignee as I cannot reproduce it locally.

(In reply to Nicolas B. Pierron [:pierron] [:nbp] from comment #6) > I cannot reproduces this on m-c. Valgrind is extremely verbose but it does > not contain any reference to popInvokeArgs. Can somebody else who can > reproduce this bug check with the patch from Bug 800862. > > Remove my-self from the assignee as I cannot reproduce it locally. Did you try with "--ion-eager"? Just checking. Assigning back to Christian Holler since we need confirmation again.

(In reply to Josh Aas (Mozilla Corporation) from comment #7) > (In reply to Nicolas B. Pierron [:pierron] [:nbp] from comment #6) > > I cannot reproduces this on m-c. Valgrind is extremely verbose but it does > > not contain any reference to popInvokeArgs. Can somebody else who can > > reproduce this bug check with the patch from Bug 800862. > > > > Remove my-self from the assignee as I cannot reproduce it locally. > > Did you try with "--ion-eager"? Just checking. Yes, valgrind with --ion-eager and --smc-check=all-non-file with both m-c and m-c + Bug 800862 patch.

(In reply to Nicolas B. Pierron [:pierron] [:nbp] from comment #8) > Yes, valgrind with --ion-eager and --smc-check=all-non-file with both m-c > and m-c + Bug 800862 patch. Just to be clear, in both cases you were not able to repro? Were you able to reproduce on the specified revision? OOM bugs sometimes are not stable across revisions and need to be checked on the original one.

JSBugMon: This bug has been automatically confirmed to be still valid (reproduced on revision 1942b4d64dc8).

(In reply to Christian Holler (:decoder) from comment #10) > JSBugMon: This bug has been automatically confirmed to be still valid > (reproduced on revision 1942b4d64dc8). What platform are you reproducing on?

The bot runs on Linux and tries the architecture specified in the bug, the rest it guesses (like debug vs. opt, in this case an opt-build is required, and options like --ion-eager). I am about to manually verify that the patch from the other bug fixes this, because the bot cannot do that.

$ o32patched/js --ion-eager test.js <no output> $ o32/js --ion-eager test.js @evaluate:1:44 out of memory Segmentation fault (core dumped) Marking as duplicate of bug 808062.

Yea, typo fix...

Great, thanks!