Closed Bug 1234414 Opened 9 years ago Closed 9 years ago

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

Categories

(Core :: JavaScript Engine, defect)

x86_64
Linux
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla46
Tracking Status
firefox46 --- fixed

People

(Reporter: decoder, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: assertion, regression, testcase, Whiteboard: [jsbugmon:update])

Attachments

(1 file)

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.
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.
Flags: needinfo?(shu)
Keywords: sec-high
Keywords: sec-high
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.
Attachment #8701301 - Flags: review?(jcoppeard)
This is not s-s. We'll get a nullptr deref in opt.
Group: javascript-core-security
Flags: needinfo?(shu)
This sounds fine to me but I'm no expert here.
Attachment #8701301 - Flags: review?(jcoppeard) → review?(jorendorff)
Whiteboard: [jsbugmon:update,bisect] → [jsbugmon:update]
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.
Is bug 1200734 a likely regressor?
Blocks: 1200734
Flags: needinfo?(terrence)
Given comment 2, I'd guess that it's more likely my patch just perturbed behavior.
Flags: needinfo?(terrence)
Attachment #8701301 - Flags: review?(jorendorff) → review+
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla46
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: