1234414 - Assertion failure: ssi_.type() == StaticScopeIter<CanGC>::Block, at js/src/vm/ScopeObject.cpp:1424 with OOM

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

The following testcase crashes on mozilla-central revision 388bdc46ba51 (build with --enable-optimize --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --disable-tests --enable-debug, run with --fuzzing-safe --no-threads):

oomTest(() => {
    var max = 400;
    function f(b) {
        if (b) {
            f(b - 1);
        } else eval('"use strict"; const z = w; z = 1 + w; c = 5');
    }
    f(max - 1);
});


Backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x0000000000aa9ce3 in js::ScopeIter::settle (this=this@entry=0x7ffffffea030) at js/src/vm/ScopeObject.cpp:1424
#0  0x0000000000aa9ce3 in js::ScopeIter::settle (this=this@entry=0x7ffffffea030) at js/src/vm/ScopeObject.cpp:1424
#1  0x0000000000aa9ff7 in js::ScopeIter::ScopeIter(JSContext*, js::AbstractFramePtr, unsigned char*, mozilla::detail::GuardObjectNotifier&&) (this=0x7ffffffea030, cx=0x7ffff6907400, frame=..., pc=<optimized out>, _notifier=<unknown type in /home/decoder/LangFuzz/work/remote/builds/debug64/dist/bin/js, CU 0x3ca370a, DIE 0x3e6bc9b>) at js/src/vm/ScopeObject.cpp:1386
#2  0x0000000000a666e5 in HandleError (regs=..., cx=0x7ffff6907400) at js/src/vm/Interpreter.cpp:1151
#3  Interpret (cx=cx@entry=0x7ffff6907400, state=...) at js/src/vm/Interpreter.cpp:3933
#4  0x0000000000a76347 in js::RunScript (cx=cx@entry=0x7ffff6907400, state=...) at js/src/vm/Interpreter.cpp:407
[...]
#127 0x00007ffffffeb370 in ?? ()
rax	0x0	0
rbx	0x7ffffffea030	140737488265264
rcx	0x7ffff6ca53b0	140737333842864
rdx	0x0	0
rsi	0x7ffff6f7a9d0	140737336814032
rdi	0x7ffff6f791c0	140737336807872
rbp	0x7ffffffe9b90	140737488264080
rsp	0x7ffffffe9b70	140737488264048
r8	0x7ffff7fe0780	140737354008448
r9	0x6372732f736a2f6c	7165916604736876396
r10	0x7ffffffe9930	140737488263472
r11	0x7ffff6c27960	140737333328224
r12	0x7ffffffea068	140737488265320
r13	0x7ffffffe9bb0	140737488264112
r14	0x7ffffffe9ff0	140737488265200
r15	0x7ffff6907418	140737330050072
rip	0xaa9ce3 <js::ScopeIter::settle()+1619>
=> 0xaa9ce3 <js::ScopeIter::settle()+1619>:	movl   $0x590,0x0
   0xaa9cee <js::ScopeIter::settle()+1630>:	callq  0x4a3f80 <abort()>


Marking this one s-s for now. The assertion seems to indicate some type issue.

Comment 1

[Christian Holler (:decoder)]

Asking :shu to look at this and also give it a security rating because he worked on the last assertion that looked like this. Honestly I have no clue what the implications of this are, if there are any security-wise.

Comment 2

[Shu-yu Guo [:shu]]

Attachment: Consider the initial values at block entry to be within block note bounds.

The bug here is that due to terrible reasons (DEFFUN), we emit lexical value
initialization for eval scripts in the *prologue*, so an eval script's prologue
might look like:

0000: uninitialized
0001: initlexical 0

Now, I think due to the now-removed let blocks and let expressions, the RHS
values used to initialize a block's bindings when entering it is considered to
be *outside* of block note bounds. That is, in the example above, the block
starts at offset 0001, not 0000.

Put these things together and we get this bug. If CallObj creation itself fails
due to OOM in a strict eval script prologue, the pc is settled on 0000, and is
considered outside of the initial block bounds, tripping this assertion.

Now that let blocks and let expressions are removed, we can include the RHS
values to be inside block note bounds.

Jon, if you don't feel comfortable reviewing this you can bounce to jorendorff.

Comment 3

[Shu-yu Guo [:shu]]

This is not s-s. We'll get a nullptr deref in opt.

Comment 4

[Jon Coppeard (:jonco)]

This sounds fine to me but I'm no expert here.

Comment 5

[Fuzzing Team]

JSBugMon: Bisection requested, result:
autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   https://hg.mozilla.org/mozilla-central/rev/0132945252d2
user:        Terrence Cole
date:        Wed Aug 26 14:51:43 2015 -0700
summary:     Bug 1200734 - Use stable hashing for LiveScopesMap; r=shu

This iteration took 292.282 seconds to run.

Comment 6

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Is bug 1200734 a likely regressor?

Comment 7

[Terrence Cole [:terrence]]

Given comment 2, I'd guess that it's more likely my patch just perturbed behavior.

Comment 8

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/71e934f9be75

Comment 9

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/71e934f9be75