808063 - IonMonkey: Opt-only Crash [@ js::ContextStack::popInvokeArgs] with OOM and invalid read

Status: RESOLVED DUPLICATE of bug 800862

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

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);\
");

Comment 1

[Christian Holler (:decoder)]

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.

Comment 2

[Nicolas B. Pierron [:nbp]]

This might be a duplicate of Bug 800862.

Comment 3

[Andrew McCreight [:mccr8]]

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

Comment 4

[David Bolter [:davidb] (NeedInfo me for attention)]

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

Comment 5

[Josh Aas]

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

Comment 6

[Nicolas B. Pierron [:nbp]]

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.

Comment 7

[Josh Aas]

(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.

Comment 8

[Nicolas B. Pierron [:nbp]]

(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.

Comment 9

[Christian Holler (:decoder)]

(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.

Comment 10

[Christian Holler (:decoder)]

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

Comment 11

[Josh Aas]

(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?

Comment 12

[Christian Holler (:decoder)]

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.

Comment 13

[Christian Holler (:decoder)]

$ 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.

Comment 14

[Christian Holler (:decoder)]

Yea, typo fix...

Comment 15

[Josh Aas]

Great, thanks!