1573001 - Crash at a weird memory address with cranelift (also shows up as a SEGV in AddressSanitizer)

Status: RESOLVED DUPLICATE of bug 1569137

(Core :: JavaScript: WebAssembly, defect)

Description

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

The following testcase crashes on mozilla-central revision c53f789ffabb (build with --enable-address-sanitizer or build with --enable-debug --enable-more-deterministic, run with --fuzzing-safe --no-threads --no-baseline --no-ion --wasm-compiler=cranelift w183-out.wrapper w183-out.wasm):

See attachment.

Backtrace of debug shell:

(gdb) bt
#0  0x000019c4f2e08426 in ?? ()
#1  0x00007fffffffb768 in ?? ()
#2  0x0000000008000803 in ?? ()
#3  0x000019c4f2ddbdc6 in ?? ()
#4  0x00007ffff553c800 in ?? ()
#5  0x00001313ffffff84 in ?? ()
#6  0x0800080300000000 in ?? ()
#7  0x00007fffffffb788 in ?? ()
#8  0x00007ffff553c800 in ?? ()
#9  0x000019c4f2de5cb2 in ?? ()
#10 0x00007fffffffb7a0 in ?? ()
#11 0x0000000000000000 in ?? ()

ASan stack:

AddressSanitizer:DEADLYSIGNAL
=================================================================
==21947==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000024 (pc 0x2044ac988426 bp 0x7fffbb4107c8 sp 0x7fffbb4107c8 T0)
==21947==The signal is caused by a READ memory access.
==21947==Hint: address points to the zero page.
    #0 0x2044ac988425  (<unknown module>)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (<unknown module>)
==21947==ABORTING

For detailed crash information, see attachment.

Setting s-s because this is a crash at a weird memory address.

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)]

Attachment: w183-out.wasm

w183-out.wrapper consists of:

new WebAssembly.Instance(new WebAssembly.Module(read(scriptArgs[0], 'binary')), {
  'fuzzing-support': {
    'log-i32': function() {},
    'log-i64': function() {},
    'log-f32': function() {},
    'log-f64': function() {},
  },
  'env': {
    'setTempRet0': function() {},
  },
}).exports.func_270_invoker();

This is the almost-reduced testcase after running wasm-reduce for ~45mins.

Comment 4

[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/d4b4afb9cd96
user: Benjamin Bouvier
date: Wed Aug 07 14:20:48 2019 +0000
summary: Bug 1571464: Bump Cranelift to c927680fd42a56efcc9a5ee59e814d9eef6c5b4f; r=jseward

Benjamin, is bug 1571464 a likely regressor?

Comment 5

[Christian Holler (:decoder)]

Attachment: w183-out.wasm

I've reduced the wasm file by using a regular reducer on the wast equivalent and then re-assembling it back to wasm for each iteration. I'll also attach the wast file in a few. This can probably still be simplified further by hand (and I would like to get the simplest form so I can check if the new generative fuzzers will find this).

Comment 6

[Christian Holler (:decoder)]

Attachment: wast for w183-out.wasm

Comment 7

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

(In reply to Christian Holler (:decoder) from comment #5)

I've reduced the wasm file by using a regular reducer on the wast equivalent and then re-assembling it back to wasm for each iteration.

That's interesting that it works! (wast -> wasm for each iteration)

I also had the idea some weeks earlier about using Lithium to do so, but other priorities came ahead. It was also a less-optimised variant. (wasm -> wast -> wasm for each iteration) I've found wasm-reduce's reduction does most of its reduction percentage (50-75%) in the first ~30 mins of reduction, the remaining (sometimes several hours'?) time we don't buy much reduction percentage for the time spent, and this is where the next stage (wast -> wasm for each iteration) of reduction could make sense.

The wrapper file on the other hand, I just use regular Lithium (line/char-based) runs.

Comment 8

[Julian Seward [:jseward]]

This is a complete guess, but .. I wonder if this is the same problem as was
fixed in bug 1569137. I can't reproduce this failure with my trunk CL build
of a couple days ago, and that contains the 1569137 fix.

Comment 9

[Benjamin Bouvier [:bbouvier] (inactive)]

Yep, I confirm that's a dup of bug 1569137. after looking at the crash and applying the fixes from this bug. It's really nice that the fuzzers could finally find it (it's been in Spidermonkey for the time Cranelift landed, so around 4th quarter of 2018), and that it could be reduced to such a small test. Closing as dup. Thanks!

Comment 10

[Liz Henry (:lizzard) (relman/hg->git project)]

Looks like a fix is on the way in bug 1569137.