1697816 - Assertion failure: (asBits_ & js::gc::CellAlignMask) == 0 (GC pointer is not aligned. Is this memory corruption?), at js/Value.h:587

Status: VERIFIED FIXED

(Core :: JavaScript Engine: JIT, defect)

Description

[Christian Holler (:decoder)]

The following testcase crashes on mozilla-central revision 20210309-5f0f6477c734 (debug build, run with --fuzzing-safe --no-threads --baseline-eager --fast-warmup --ion-gvn=off --scalar-replace-arguments):

function a(b) {
  return String(b);
}
function c(d, e = []) {
  f = new Proxy(d, {
    get(g, b) {
      k = e.concat(a(b));
      h = d;
      c(h).apply;
    }
  })
  return f;
}
[] = c([]);

Backtrace:

received signal SIGSEGV, Segmentation fault.
0x584c71dc in js::jit::AssertValidValue(JSContext*, JS::Value*) ()
#0  0x584c71dc in js::jit::AssertValidValue(JSContext*, JS::Value*) ()
#1  0x31b15143 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
eax	0x56763cae	1450589358
ebx	0x58ec0fa4	1491865508
ecx	0x58ec2894	1491871892
edx	0x0	0
esi	0xfffed9e8	-75288
edi	0xfffeda24	-75228
ebp	0xfffeda08	4294892040
esp	0xfffed9e0	4294892000
eip	0x584c71dc <js::jit::AssertValidValue(JSContext*, JS::Value*)+236>
=> 0x584c71dc <_ZN2js3jit16AssertValidValueEP9JSContextPN2JS5ValueE+236>:	movl   $0x24b,0x0
   0x584c71e6 <_ZN2js3jit16AssertValidValueEP9JSContextPN2JS5ValueE+246>:	call   0x5799e16f <abort>

Not s-s because this feature is still disabled by default. Reproduces on 32-bit builds only.

Comment 1

[Christian Holler (:decoder)]

Attachment: Testcase

Comment 2

[Bugmon [:jkratzer for issues]]

Bugmon Analysis:
Verified bug as reproducible on mozilla-central 20210311093001-bd8121e747b5.
The bug appears to have been introduced in the following build range:

Start: b332567cbbcaa6e2b70bfe5449410e9cfb8b838f (20210309094921)
End: 5f0f6477c734369a72fec1211b608eb14d33bd4a (20210309161138)
Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b332567cbbcaa6e2b70bfe5449410e9cfb8b838f&tochange=5f0f6477c734369a72fec1211b608eb14d33bd4a

Comment 3

[Iain Ireland [:iain]]

Attachment: Bug 1697816: Fix moveValue when src == typeReg r=jandem

This is very similar to bug 1697483, in that it happens because we are reusing the source of a moveValue as part of the destination. I glanced at the 32-bit code when I fixed that, but missed this problem.

We should not set the tag register until after we copy the src into the payloadReg, because that breaks when src and typeReg are assigned the same register. Swapping the order fixes the problem.

I fixed MIPS while I was at it. ARM64 doesn't need a fix, because it can set the tag without a scratch register.

I'm not adding a new testcase here, because I already gave it my best shot in bug 1697483 and it doesn't catch this problem. Specific register allocation patterns are hard to test. It does seem like the fuzzer catches these cases quickly, though.

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/6b87ba86385f
Fix moveValue when src == typeReg r=jandem

Comment 5

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/6b87ba86385f

Comment 6

[Bugmon [:jkratzer for issues]]

Bugmon Analysis:
Verified bug as fixed on rev mozilla-central 20210312215843-658f0e3e5bcc.
Removing bugmon keyword as no further action possible.
Please review the bug and re-add the keyword for further analysis.