1548611 - Assertion failure: maybeCCWRealm() == group->realm(), at js/src/vm/JSObject-inl.h:120

Status: VERIFIED FIXED

(Core :: JavaScript Engine: JIT, defect)

Description

[Christian Holler (:decoder)]

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.

Comment 1

[Andrew McCreight [:mccr8]]

Jan, any ideas? Thanks.

Comment 2

[Fuzzing Team]

JSBugMon: The testcase found in this bug no longer reproduces (tried revision 6fd64908d113).
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/2b2554ff8f8c
user:        Ted Campbell
date:        Wed Apr 17 16:07:14 2019 +0000
summary:     Bug 1406146 - Use ShellWindowProxy in jsshell by default. r=jandem,jorendorff

This iteration took 503.409 seconds to run.

Comment 3

[Iain Ireland [:iain]]

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.

Comment 4

[Iain Ireland [:iain]]

Attachment: Bug 1548611: Update RNewArray::recover to match CodeGenerator::visitNewArrayCallVM r=jandem

Comment 5

[Jan de Mooij [:jandem]]

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

[Ryan VanderMeulen [:RyanVM]]

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

Comment 7

[Fuzzing Team]

JSBugMon: This bug has been automatically verified fixed.