1204725 - Crash [@ js::FrameIter::copyData] with OOM

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

The following testcase crashes on mozilla-central revision 9ed17db42e3e (build with --enable-optimize --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --target=i686-pc-linux-gnu --disable-tests --enable-debug, run with --fuzzing-safe --thread-count=2 --ion-extra-checks --baseline-eager --ion-eager --ion-check-range-analysis):

function oomTest(f) {
    var i = 1;
    do {
        try {
            oomAtAllocation(i);
            f();
        } catch (e) {}
        more = resetOOMFailure();
        i++;
    } while(more);
}
var g = newGlobal();
g.parent = this;
g.eval("new Debugger(parent).onExceptionUnwind = function () { };");
oomTest(function() {
  var wm = new WeakMap();
  wm.set(i, 'FOO').get(false);
});



Backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x083bef50 in js::FrameIter::copyData (this=this@entry=0xffffb1d0) at js/src/vm/Stack.cpp:762
#0  0x083bef50 in js::FrameIter::copyData (this=this@entry=0xffffb1d0) at js/src/vm/Stack.cpp:762
#1  0x083bf00b in js::FrameIter::copyDataAsAbstractFramePtr (this=0xffffb1d0) at js/src/vm/Stack.cpp:770
#2  0x082eddc6 in js::Debugger::getScriptFrameWithIter (this=this@entry=0xf7a51000, cx=cx@entry=0xf7a033d0, frame=..., maybeIter=maybeIter@entry=0xffffb1d0, vp=vp@entry=...) at js/src/vm/Debugger.cpp:470
#3  0x08318fa6 in getScriptFrame (vp=..., iter=..., cx=0xf7a033d0, this=0xf7a51000) at js/src/vm/Debugger.h:883
#4  js::Debugger::fireExceptionUnwind (this=this@entry=0xf7a51000, cx=cx@entry=0xf7a033d0, vp=vp@entry=...) at js/src/vm/Debugger.cpp:1213
#5  0x08319570 in operator() (dbg=0xf7a51000, __closure=<synthetic pointer>) at js/src/vm/Debugger.cpp:733
#6  dispatchHook<js::Debugger::slowPathOnExceptionUnwind(JSContext*, js::AbstractFramePtr)::__lambda4, js::Debugger::slowPathOnExceptionUnwind(JSContext*, js::AbstractFramePtr)::__lambda5> (fireHook=..., cx=0xf7a033d0, hookIsEnabled=...) at js/src/vm/Debugger.cpp:1392
#7  js::Debugger::slowPathOnExceptionUnwind (cx=0xf7a033d0, frame=frame@entry=...) at js/src/vm/Debugger.cpp:734
#8  0x08621bf6 in onExceptionUnwind (frame=..., cx=<optimized out>) at js/src/vm/Debugger-inl.h:58
#9  HandleExceptionBaseline (pc=<optimized out>, rfe=<optimized out>, frame=..., cx=<optimized out>) at js/src/jit/JitFrames.cpp:718
#10 js::jit::HandleException (rfe=0xffffb8d4) at js/src/jit/JitFrames.cpp:899
#11 0xf7fc8335 in ?? ()
#12 0xf7fd559a in ?? ()
#13 0xf7a21ec0 in ?? ()
#14 0xf7fc8c5c in ?? ()
#15 0x084ec0b5 in EnterBaseline (cx=0xf7a22030, cx@entry=0xf7a033d0, data=...) at js/src/jit/BaselineJIT.cpp:126
#16 0x08501145 in js::jit::EnterBaselineMethod (cx=cx@entry=0xf7a033d0, state=...) at js/src/jit/BaselineJIT.cpp:157
#17 0x08314c20 in js::RunScript (cx=cx@entry=0xf7a033d0, state=...) at js/src/vm/Interpreter.cpp:694
#18 0x08315352 in js::Invoke (cx=cx@entry=0xf7a033d0, args=..., construct=construct@entry=js::NO_CONSTRUCT) at js/src/vm/Interpreter.cpp:781
#19 0x083172ae in js::Invoke (cx=cx@entry=0xf7a033d0, thisv=..., fval=..., argc=argc@entry=1, argv=argv@entry=0xffffc280, rval=rval@entry=...) at js/src/vm/Interpreter.cpp:818
#20 0x08576d72 in js::jit::DoCallFallback (cx=0xf7a033d0, frame=0xffffc2b0, stub_=0xf7a21350, argc=1, vp=0xffffc270, res=...) at js/src/jit/BaselineIC.cpp:8899
#21 0xf7fccffe in ?? ()
#22 0xf7a21350 in ?? ()
#23 0xf7fc8c5c in ?? ()
#24 0x084ec0b5 in EnterBaseline (cx=0xf7a21350, cx@entry=0xf7a033d0, data=...) at js/src/jit/BaselineJIT.cpp:126
#25 0x08501145 in js::jit::EnterBaselineMethod (cx=cx@entry=0xf7a033d0, state=...) at js/src/jit/BaselineJIT.cpp:157
#26 0x08314c20 in js::RunScript (cx=cx@entry=0xf7a033d0, state=...) at js/src/vm/Interpreter.cpp:694
#27 0x0831f608 in js::ExecuteKernel (cx=cx@entry=0xf7a033d0, script=..., script@entry=..., scopeChainArg=..., thisv=..., newTargetValue=..., type=type@entry=js::EXECUTE_GLOBAL, evalInFrame=evalInFrame@entry=..., result=result@entry=0x0) at js/src/vm/Interpreter.cpp:978
#28 0x08321ad4 in js::Execute (cx=cx@entry=0xf7a033d0, script=script@entry=..., scopeChainArg=..., rval=rval@entry=0x0) at js/src/vm/Interpreter.cpp:1012
#29 0x0876ea7d in ExecuteScript (cx=cx@entry=0xf7a033d0, scope=..., script=script@entry=..., rval=rval@entry=0x0) at js/src/jsapi.cpp:4362
#30 0x0876ec06 in JS_ExecuteScript (cx=cx@entry=0xf7a033d0, scriptArg=scriptArg@entry=...) at js/src/jsapi.cpp:4393
#31 0x0806b50f in RunFile (compileOnly=false, file=0xf7ae29e0, filename=0xffffcffc "min.js", cx=0xf7a033d0) at js/src/shell/js.cpp:462
#32 Process (cx=cx@entry=0xf7a033d0, filename=0xffffcffc "min.js", forceTTY=forceTTY@entry=false) at js/src/shell/js.cpp:580
#33 0x080d2629 in ProcessArgs (op=0xffffcc60, cx=<optimized out>) at js/src/shell/js.cpp:5834
#34 Shell (envp=<optimized out>, op=0xffffcc60, cx=<optimized out>) at js/src/shell/js.cpp:6123
#35 main (argc=8, argv=0xffffcdb4, envp=0xffffcdd8) at js/src/shell/js.cpp:6472
eax	0x0	0
ebx	0x97b5934	159078708
ecx	0xffffb904	-18172
edx	0xf7a033d0	-140495920
esi	0xffffb1d0	-20016
edi	0x0	0
ebp	0xffffaff8	4294946808
esp	0xffffafc0	4294946752
eip	0x83bef50 <js::FrameIter::copyData() const+240>
=> 0x83bef50 <js::FrameIter::copyData() const+240>:	mov    %edx,(%eax)
   0x83bef52 <js::FrameIter::copyData() const+242>:	add    $0x2c,%esp


This one behaves intermittently but I wasn't able to get it more reliably working with the new per-thread functionality. Maybe some thread has to run before another for the faulty condition to be even possible.

Comment 1

[Fuzzing Team]

JSBugMon: Cannot process bug: Unable to automatically reproduce, please track manually.

Comment 2

[Fuzzing Team]

JSBugMon: Bisection requested, result:
=== Treeherder Build Bisection Results by autoBisect ===

The "good" changeset has the timestamp "20150904085034" and the hash "01970916deda39d56a2c016a94d5132ea110afa0".
The "bad" changeset has the timestamp "20150904090734" and the hash "34c126018a48aa2c8a76f5a448adaee7324917ea".

Likely regression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=01970916deda39d56a2c016a94d5132ea110afa0&tochange=34c126018a48aa2c8a76f5a448adaee7324917ea

Comment 3

[Nicolas B. Pierron [:nbp]]

(In reply to Fuzzing Team from comment #2)
> https://hg.mozilla.org/integration/mozilla-inbound/
> pushloghtml?fromchange=01970916deda39d56a2c016a94d5132ea110afa0&tochange=34c1
> 26018a48aa2c8a76f5a448adaee7324917ea

This regression window sounds unrelated to the shell test case.  I that that the command line uses --thread-count=2, could it be intermittent?

Comment 4

[Hannes Verschore [:h4writer]]

Attachment: Patch

Comment 5

[Nicolas B. Pierron [:nbp]]

Comment on attachment 8661710 [details] [diff] [review]
Patch

Review of attachment 8661710 [details] [diff] [review]:
-----------------------------------------------------------------

Sounds good, apparently the rest of the code is already checking the return value properly.

Comment 6

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/f9f33ed1f4da

Comment 7

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/f9f33ed1f4da