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)
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)
2.03 KB,
patch
|
jorendorff
:
review+
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Comment 1•9 years ago
|
||
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
Comment 2•9 years ago
|
||
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)
Comment 3•9 years ago
|
||
This is not s-s. We'll get a nullptr deref in opt.
Group: javascript-core-security
Flags: needinfo?(shu)
Comment 4•9 years ago
|
||
This sounds fine to me but I'm no expert here.
Updated•9 years ago
|
Attachment #8701301 -
Flags: review?(jcoppeard) → review?(jorendorff)
Updated•9 years ago
|
Whiteboard: [jsbugmon:update,bisect] → [jsbugmon:update]
Comment 5•9 years ago
|
||
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)
Comment 7•9 years ago
|
||
Given comment 2, I'd guess that it's more likely my patch just perturbed behavior.
Flags: needinfo?(terrence)
Updated•9 years ago
|
Attachment #8701301 -
Flags: review?(jorendorff) → review+
Comment 9•9 years ago
|
||
bugherder |
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.
Description
•