Assertion failure: maybeCCWRealm() == group->realm(), at js/src/vm/JSObject-inl.h:120
Categories
(Core :: JavaScript Engine: JIT, defect)
Tracking
()
People
(Reporter: decoder, Assigned: iain)
Details
(4 keywords, Whiteboard: [jsbugmon:update,ignore][adv-main68+])
Attachments
(1 file)
The following testcase crashes on mozilla-central revision e8766f96041a (build with --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --disable-tests --disable-profiling --enable-debug --enable-optimize, run with --fuzzing-safe --cpu-count=2 --ion-offthread-compile=off --ion-warmup-threshold=0):
const otherGlobal = newGlobal();
function f() {
new otherGlobal.Array();
}
for (var i=0; i<60; i++) {
g = otherGlobal;
f();
f();
g.toString()
}
Backtrace:
received signal SIGSEGV, Segmentation fault.
#0 JSObject::setGroup (this=0x39b52a700dd8, group=0x22604e7b7280) at js/src/vm/JSObject-inl.h:120
#1 0x00005555559238d3 in NewArrayTryUseGroup<4294967295u> (cx=<optimized out>, group=..., length=0, newKind=<optimized out>) at js/src/builtin/Array.cpp:4225
#2 0x00005555563cad7f in js::jit::RNewArray::recover (this=0x7fffffffb5c8, cx=<optimized out>, iter=...) at js/src/jit/Recover.cpp:1244
#3 0x000055555630bce0 in js::jit::SnapshotIterator::computeInstructionResults (this=this@entry=0x7fffffffb670, cx=cx@entry=0x7ffff5f19000, results=results@entry=0x7fffffffc540) at js/src/jit/JitFrames.cpp:1906
#4 0x000055555630c0a3 in js::jit::SnapshotIterator::initInstructionResults (this=this@entry=0x7fffffffbdc0, fallback=...) at js/src/jit/JitFrames.cpp:1860
#5 0x000055555667a7a2 in js::jit::BailoutIonToBaseline (cx=<optimized out>, cx@entry=0x7ffff5f19000, activation=<optimized out>, iter=..., invalidate=invalidate@entry=true, bailoutInfo=bailoutInfo@entry=0x7fffffffc160, excInfo=excInfo@entry=0x0) at js/src/jit/BaselineBailouts.cpp:1737
#6 0x000055555667f761 in js::jit::InvalidationBailout (sp=<optimized out>, frameSizeOut=0x7fffffffc168, bailoutInfo=0x7fffffffc160) at js/src/jit/Bailouts.cpp:134
#7 0x00002978aea99628 in ?? ()
#8 0x00007fffffffc1a0 in ?? ()
#9 0x00007fffffffc160 in ?? ()
#10 0x0000000000000000 in ?? ()
rax 0x555557c9d9a0 93825033427360
rbx 0x22604e7b7280 37797028917888
rcx 0x7ffff6c1c2dd 140737333281501
rdx 0x555556b662d8 93825015374552
rsi 0x7ffff6eeb770 140737336227696
rdi 0x7ffff6eea540 140737336223040
rbp 0x7fffffffb390 140737488335760
rsp 0x7fffffffb380 140737488335744
r8 0x7ffff6eeb770 140737336227696
r9 0x7ffff7fe6cc0 140737354034368
r10 0x58 88
r11 0x7ffff6b927a0 140737332717472
r12 0x39b52a700dd8 63450263850456
r13 0x39b52a700dd8 63450263850456
r14 0x0 0
r15 0x1 1
rip 0x5555558f1139 <JSObject::setGroup(js::ObjectGroup*)+249>
=> 0x5555558f1139 <JSObject::setGroup(js::ObjectGroup*)+249>: movl $0x0,0x0
0x5555558f1144 <JSObject::setGroup(js::ObjectGroup*)+260>: ud2
Marking s-s until investigated because this is related to CCWs and JIT.
Updated•6 years ago
|
Comment 2•6 years ago
|
||
Assignee | ||
Comment 3•6 years ago
|
||
I poked around at this as a distraction from TISnapshot. I think the bug still exists, but was covered up by my call IC changes. (Not sure why the bisection turned up Ted's changeset.)
Specifically, when I made a new version of GetTemplateObjectForNative in CacheIR.cpp, I missed the new AutoRealm added in this changeset. Because of this, we started failing this test in inlineArray, which prevented us from reaching the bug.
If I put an AutoRealm at the beginning of CallIRGenerator::getTemplateObjectForNative, then the bug reappears. Here's a slightly simplified testcase (run with --ion-eager --ion-offthread-compile=off):
const otherGlobal = newGlobal();
for (var i=0; i<60; i++) {
new otherGlobal.Array();
bailout();
}
Because the new array is unused, we don't actually generate it until we bail out. At that point, the recovery instruction tries to recreate it. We end up in almost exactly the situation that anba described in this Phabricator comment: we create an Array in one realm, try to set its group to a group in a different realm, and trigger an assertion.
Adding a conditional AutoRealm in RNewArray::recover (which should become an AutoSameCompartmentRealm if/when that change happens) fixes the testcase.
Assignee | ||
Comment 4•6 years ago
|
||
Updated•6 years ago
|
Comment 5•6 years ago
|
||
Downgrading to sec-moderate but I think it's not even a security bug. setGroup is asserting against changing an object's group to one from a different realm (because that's weird and usually a bug) but in this case it ends up doing the right thing.
Comment 6•6 years ago
|
||
Comment 7•6 years ago
|
||
Updated•6 years ago
|
Updated•5 years ago
|
Description
•