1445992 - MOZ_CRASH() with ALIGNMENT EXCEPTION [@ vixl::Simulator::AddressModeHelper]

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine: JIT, defect, P3)

Description

[Christian Holler (:decoder)]

The following testcase crashes on mozilla-central revision fcb11e93adf5+ (build with --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --disable-tests --disable-profiling --enable-debug --enable-optimize --enable-simulator=arm64, run with --fuzzing-safe):

var g = newGlobal();
g.parent = this;
g.eval("(" + function() {
    var dbg = Debugger(parent);
    dbg.onEnterFrame = function(frame) {
        frame.onStep = function() {}
    }
} + ")()");
eval(`
  try {} catch(exc) {
    try {} catch(lfVare5) {}
  }
  if (({x:3}) | (this) && 1 || unescape() === 0)
    unescape(0);
  var lfGlobal = newGlobal();
  2 == 0 ? i < a.length   : 1     ;
  for (lfLocal in this) {}
`);


Backtrace:

received signal SIGSEGV, Segmentation fault.
0x000000000049236a in mozalloc_abort (msg=msg@entry=0x1263858 "Redirecting call to abort() to mozalloc_abort\n") at memory/mozalloc/mozalloc_abort.cpp:33
#0  0x000000000049236a in mozalloc_abort (msg=msg@entry=0x1263858 "Redirecting call to abort() to mozalloc_abort\n") at memory/mozalloc/mozalloc_abort.cpp:33
#1  0x0000000000492340 in abort () at memory/mozalloc/mozalloc_abort.cpp:80
#2  0x00000000009dcba8 in vixl::Simulator::AddressModeHelper (this=<optimized out>, addr_reg=<optimized out>, offset=16, addrmode=vixl::PostIndex) at js/src/jit/arm64/vixl/Simulator-vixl.cpp:1470
#3  0x00000000009e1a9a in vixl::Simulator::LoadStorePairHelper (this=0x7ffff5f3b000, instr=0x21de2be08b7c, addrmode=vixl::PostIndex) at js/src/jit/arm64/vixl/Simulator-vixl.cpp:1150
#4  0x000000000094d6c8 in vixl::Decoder::VisitLoadStorePairPostIndex (this=<optimized out>, instr=0x21de2be08b7c) at js/src/jit/arm64/vixl/Decoder-vixl.cpp:872
#5  0x00000000009d4d75 in vixl::Decoder::Decode (instr=<optimized out>, this=<optimized out>) at js/src/jit/arm64/vixl/Decoder-vixl.h:158
#6  vixl::Simulator::ExecuteInstruction (this=0x7ffff5f3b000) at js/src/jit/arm64/vixl/MozSimulator-vixl.cpp:195
#7  0x00000000009d73cc in vixl::Simulator::Run (this=0x7ffff5f3b000) at js/src/jit/arm64/vixl/Simulator-vixl.cpp:68
#8  0x00000000009d523d in vixl::Simulator::RunFrom (first=0x21de2be08970, this=0x7ffff5f3b000) at js/src/jit/arm64/vixl/Simulator-vixl.cpp:76
#9  vixl::Simulator::call (this=0x7ffff5f3b000, entry=entry@entry=0x21de2be08970 "\376w\277\251\375\003", argument_count=argument_count@entry=8) at js/src/jit/arm64/vixl/MozSimulator-vixl.cpp:326
#10 0x0000000000622e4e in EnterBaseline (data=..., cx=0x7ffff5f16000) at js/src/jit/BaselineJIT.cpp:151
#11 js::jit::EnterBaselineAtBranch (cx=0x7ffff5f16000, fp=0x7ffff45730b8, pc=<optimized out>) at js/src/jit/BaselineJIT.cpp:226
#12 0x000000000056d278 in Interpret (cx=0x7ffff5f16000, state=...) at js/src/vm/Interpreter.cpp:2038
[...]
#27 0x0000000000442f92 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at js/src/shell/js.cpp:9410
rax	0x0	0
rbx	0x7ffff6ef6700	140737336272640
rcx	0x7ffff6c282ad	140737333330605
rdx	0x0	0
rsi	0x7ffff6ef7770	140737336276848
rdi	0x7ffff6ef6540	140737336272192
rbp	0x7fffffffb190	140737488335248
rsp	0x7fffffffb180	140737488335232
r8	0x7ffff6ef7770	140737336276848
r9	0x7ffff7fe4780	140737354024832
r10	0x0	0
r11	0x0	0
r12	0x2	2
r13	0x21de2be08b7c	37238102592380
r14	0x2	2
r15	0x7fffffffb410	140737488335888
rip	0x49236a <mozalloc_abort(char const*)+42>
=> 0x49236a <mozalloc_abort(char const*)+42>:	movl   $0x0,0x0
   0x492375 <mozalloc_abort(char const*)+53>:	ud2

Comment 1

[Lars T Hansen [:lth]]

JS baseline code, not wasm.

Comment 2

[Lars T Hansen [:lth]]

I can repro on Linux (but not on Mac).

The reason for the fault is that the SP is not properly 16-byte aligned, indeed it has the very unlikely value 0x1007b7ff436186b.  The last instructions executed were:

0x000031101f65bb24  910003fc		mov     x28, sp
0x000031101f65bb28  f940039c		ldr     x28, [x28]
0x000031101f65bb2c  f840879e		ldr     x30, [x28], #8
0x000031101f65bb30  9100039f		mov     sp, x28
0x000031101f65bb34  a8c15f93		ldp     x19, x23, [x28], #16
0x000031101f65bb38  9100639c		add     x28, x28, #0x18 (24)
0x000031101f65bb3c  9100c2f7		add     x23, x23, #0x30 (48)
0x000031101f65bb40  72001c1f		tst     w0, #0xff
0x000031101f65bb44  54000040		b.eq    #+0x8 (addr 0x31101f65bb4c)
0x000031101f65bb48  d61f0260		br      x19
0x000031101f67e62c  d63f0220		blr     x17
0x000031101f65bb70  f8408793		ldr     x19, [x28], #8
0x000031101f65bb74  8b53239c		add     x28, x28, x19, lsr #8
0x000031101f65bb78  9100039f		mov     sp, x28
0x000031101f65bb7c  a8c15ff8		ldp     x24, x23, [sp], #16

Since the SP is the result of loading a value from the stack and adding that to the PSP and then moving the PSP to the SP, we should probably assume that the frame is corrupted or that the PSP is wrong.

Comment 3

[Chris Peterson [:cpeterson]]

[arm64:m2] because a simulator fuzz crash doesn't block publishing ARM64 Fennec Nightly builds.

Comment 4

[Chris Peterson [:cpeterson]]

[arm64:m4] because simulator bugs don't need to block shipping ARM64 Fennec.

Comment 5

[Sean Stangl [:sstangl]]

I'm downgrading the severity of this bug from "P2 Critical" to P3 on the basis that this crash is Simulator-only, and we currently fuzz on real hardware. Fixing this bug would not unblock anything: therefore it's not a P2.

This is redundant with it having already been marked "fix-optional" a year ago.

Before we go spending time fixing the Simulator, it would be prudent to perform a VIXL upgrade (3-4 week project that I don't have time-budget allocated for at the moment).

Comment 6

[Nicolas B. Pierron [:nbp]]

I am not able to reproduce this issue on top of the latest mozilla/central.
Decoder, does it reproduce for you?

Comment 7

[Christian Holler (:decoder)]

This doesn't reproduce for me anymore either (also not when adding --more-compartments).