1526568 - AddressSanitizer: Crash [@ unsigned long vixl::Memory::Read]

Status: RESOLVED DUPLICATE of bug 1526579

(Core :: JavaScript: WebAssembly, defect)

Description

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

The following testcase crashes on mozilla-central revision 22ca3a5f976f (build with --enable-debug --enable-simulator=arm64, run with --fuzzing-safe --no-threads --no-baseline --no-ion w251-out.wrapper w251-out.wasm):

See attachment.

Backtrace:

AddressSanitizer:DEADLYSIGNAL

==1926==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x55c02dbae354 bp 0x7fffacbd1b50 sp 0x7fffacbd11c0 T0)
==1926==The signal is caused by a READ memory access.
==1926==Hint: address points to the zero page.
#0 0x55c02dbae353 in unsigned long vixl::Memory::Read<unsigned long, unsigned long>(unsigned long) js/src/jit/arm64/vixl/Simulator-vixl.h:265:5
#1 0x55c02dbae353 in unsigned long vixl::Simulator::Read<unsigned long>(unsigned long) js/src/jit/arm64/vixl/Simulator-vixl.cpp:1042
#2 0x55c02dbae353 in vixl::Simulator::LoadStoreHelper(vixl::Instruction const*, long, vixl::AddrMode) js/src/jit/arm64/vixl/Simulator-vixl.cpp:1069
#3 0x55c02dad7b39 in vixl::Decoder::VisitLoadStoreUnsignedOffset(vixl::Instruction const*) js/src/jit/arm64/vixl/Decoder-vixl.cpp:872:1
#4 0x55c02dad7b39 in vixl::Decoder::DecodeLoadStore(vixl::Instruction const*) js/src/jit/arm64/vixl/Decoder-vixl.cpp:382
#5 0x55c02db8189d in vixl::Simulator::ExecuteInstruction() js/src/jit/arm64/vixl/Decoder-vixl.h:158:5
/snip

For detailed crash information, see attachment.

While this seems to be specific to the ARM64 simulator, it does show up as an Asan error, so setting s-s as a start.

Comment 1

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Attachment: Detailed Crash Information

Comment 2

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Attachment: Testcase

Comment 3

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

autobisectjs shows this is probably related to the following changeset:

The first bad revision is:
changeset: https://hg.mozilla.org/mozilla-central/rev/45b378c260d9
parent: 447946:3214fd9390a0
user: Lars T Hansen
date: Mon Nov 19 09:45:32 2018 +0100
summary: Bug 1507785 - Use logical, not physical, frame size at block exit. r=bbouvier

Lars, is bug 1507785 a likely regressor?

Comment 4

[Lars T Hansen [:lth]]

Given the symptoms, this is somewhat likely a dup of bug 1526579.

Comment 5

[Lars T Hansen [:lth]]

Indeed fixed by the patch for bug 1526579.

Comment 6

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Attachment: test.wrapper

Compile a js shell with --enable-debug --enable-simulator=arm64 at m-c rev 22ca3a5f976f and run with --fuzzing-safe --no-threads --no-baseline --no-ion test.wrapper "$(<path to>/wasm-as test.wast -o out.wasm && ls out.wasm)"

(Download binaryen v84 x86_64 tarball which contains wasm-as from: https://github.com/WebAssembly/binaryen/releases/tag/version_84 )

This reduction was done to get a smaller testcase via wasm-reduce.

$ ./js-dbg-64-armsim64-linux-x86_64-22ca3a5f976f --fuzzing-safe --no-threads --no-baseline --no-ion test.wrapper "$(binaryen-version_84/wasm-as test.wast -o out.wasm && ls out.wasm)"
Segmentation fault

Comment 7

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Attachment: test.wast

Comment 8

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Attachment: out.wasm

A .wast textual representation of the attached out.wasm file:

(module
 (type $0 (func))
 (type $1 (func (result f64)))
 (type $2 (func (param i32 f64 i64 i64 i32 i64 f64) (result f32)))
 (type $3 (func (result i32)))
 (type $4 (func (param i32 i32) (result i32)))
 (import "fuzzing-support" "log-i32" (func $fimport$0 (param i32)))
 (export "func_110_invoker" (func $4))
 (func $0 (; 1 ;) (type $3) (result i32)
  (i32.const 1)
 )
 (func $1 (; 2 ;) (type $2) (param $0 i32) (param $1 f64) (param $2 i64) (param $3 i64) (param $4 i32) (param $5 i64) (param $6 f64) (result f32)
  (call $fimport$0
   (local.get $4)
  )
  (f32.const 8)
 )
 (func $2 (; 3 ;) (type $4) (param $0 i32) (param $1 i32) (result i32)
  (local $2 i32)
  (local $3 i32)
  (local $4 i64)
  (block $label$1 (result i32)
   (br_if $label$1
    (local.tee $2
     (i32.const 8)
    )
    (block $label$2 (result i32)
     (drop
      (call $1
       (local.get $2)
       (call $3)
       (local.get $4)
       (i64.add
        (i64.const 1)
        (i64.const 7)
       )
       (local.tee $3
        (i32.const 0)
       )
       (local.get $4)
       (if (result f64)
        (i32.const 1)
        (f64.const 8)
        (f64.convert_i32_s
         (br_if $label$2
          (loop $label$5 (result i32)
           (i32.const 0)
          )
          (call $0)
         )
        )
       )
      )
     )
     (unreachable)
    )
   )
  )
 )
 (func $3 (; 4 ;) (type $1) (result f64)
  (f64.const 1)
 )
 (func $4 (; 5 ;) (type $0)
  (drop
   (call $2
    (i32.const 0)
    (i32.const 4)
   )
  )
 )
)

with an out.wrapper file of:

binary = read(scriptArgs[0], 'binary')
instance = new WebAssembly.Instance(new WebAssembly.Module(binary), {
    'fuzzing-support': {
        'log-i32': function() {},
    }
})
instance.exports.func_110_invoker();

is the ultimate smallest testcase I can come up with.

Compile a js shell with --enable-debug --enable-simulator=arm64 at m-c rev 22ca3a5f976f and run with --fuzzing-safe --no-threads --no-baseline --no-ion out.wrapper out.wasm