Stream: git-wasmtime

Topic: wasmtime / issue #3135 fuzzing: failed to instantiate mod...

view this post on Zulip Wasmtime GitHub notifications bot (Aug 02 2021 at 16:05):

abrown opened issue #3135:

Test Case

(module
      (type (;0;) (func))
      (func (;0;) (type 0)
        global.get 0
        i32.eqz
        if  ;; label = @1
          unreachable
        end
        global.get 0
        i32.const 1
        i32.sub
        global.set 0)
      (memory (;0;) 0 1)
      (global (;0;) (mut i32) (i32.const 1000))
      (export "" (func 0))
      (export "\0e" (func 0))
      (data (;0;) (i32.const 249) ""))

Configuration:

Config {
        opt_level: None,
        debug_info: true,
        canonicalize_nans: false,
        interruptable: true,
        consume_fuel: false,
        static_memory_maximum_size: None,
        static_memory_guard_size: None,
        dynamic_memory_guard_size: None,
        guard_before_linear_memory: false,
    }

Steps to Reproduce

I have verified that running Wasmtime directly on this module (cargo +nightly run -- run -g scratch.wat) does not fail so I think the bug is related to how things are configured in the fuzzing oracles.

Expected Results

Instantiate the module while fuzzing.

Actual Results

thread '<unnamed>' panicked at 'Wasmtime can instantiate module: wasm trap: out of bounds memory access', crates/fuzzing/src/oracles.rs:820:10
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
==1092110== ERROR: libFuzzer: deadly signal
    #0 0x564048087231 in __sanitizer_print_stack_trace /rustc/llvm/src/llvm-project/compiler-rt/lib/asan/asan_stack.cpp:86:3
    #1 0x56404ca2b3f8 in fuzzer::PrintStackTrace() (/home/abrown/Code/wasmtime/target/x86_64-unknown-linux-gnu/release/differential_spec+0x5ff83f8)
    #2 0x56404ca4d8b5 in fuzzer::Fuzzer::CrashCallback() (/home/abrown/Code/wasmtime/target/x86_64-unknown-linux-gnu/release/differential_spec+0x601a8b5)
    #3 0x7f4a185bca1f  (/lib64/libpthread.so.0+0x13a1f)
    #4 0x7f4a182ca2a1 in raise (/lib64/libc.so.6+0x3d2a1)
    #5 0x7f4a182b38a3 in abort (/lib64/libc.so.6+0x268a3)
    #6 0x56404cac60f6 in std::sys::unix::abort_internal::h41ede9a5caf8d829 /rustc/b41936b92cd8463020207cb2f62a4247942ef2e4/library/std/src/sys/unix/mod.rs:255:14
    #7 0x564048000a45 in std::process::abort::h1cff6c22924aaee7 /rustc/b41936b92cd8463020207cb2f62a4247942ef2e4/library/std/src/process.rs:1957:5
    #8 0x56404ca1b7bb in libfuzzer_sys::initialize::_$u7b$$u7b$closure$u7d$$u7d$::h9890a57d769a69b1 (/home/abrown/Code/wasmtime/target/x86_64-unknown-linux-gnu/release/differential_spec+0x5fe87bb)
    #9 0x56404cab94f8 in std::panicking::rust_panic_with_hook::h3039e236b6ca482c /rustc/b41936b92cd8463020207cb2f62a4247942ef2e4/library/std/src/panicking.rs:626:17
    #10 0x56404cab8fb6 in std::panicking::begin_panic_handler::_$u7b$$u7b$closure$u7d$$u7d$::h884fbab544ffd91c /rustc/b41936b92cd8463020207cb2f62a4247942ef2e4/library/std/src/panicking.rs:519:13
    #11 0x56404cab54ab in std::sys_common::backtrace::__rust_end_short_backtrace::hdaf2e18ba3d91210 /rustc/b41936b92cd8463020207cb2f62a4247942ef2e4/library/std/src/sys_common/backtrace.rs:141:18
    #12 0x56404cab8f18 in rust_begin_unwind /rustc/b41936b92cd8463020207cb2f62a4247942ef2e4/library/std/src/panicking.rs:515:5
    #13 0x564048003180 in core::panicking::panic_fmt::hcf5f6d96e1dd7099 /rustc/b41936b92cd8463020207cb2f62a4247942ef2e4/library/core/src/panicking.rs:92:14
    #14 0x564048003272 in core::result::unwrap_failed::he898b02f57993c42 /rustc/b41936b92cd8463020207cb2f62a4247942ef2e4/library/core/src/result.rs:1599:5
    #15 0x5640484fb300 in wasmtime_fuzzing::oracles::run_in_wasmtime::h575888b49fa4ed1e (/home/abrown/Code/wasmtime/target/x86_64-unknown-linux-gnu/release/differential_spec+0x1ac8300)
    #16 0x5640484f7de6 in wasmtime_fuzzing::oracles::differential_spec_execution::h74b73ab98332e7b0 (/home/abrown/Code/wasmtime/target/x86_64-unknown-linux-gnu/release/differential_spec+0x1ac4de6)
    #17 0x564048298e2e in rust_fuzzer_test_input (/home/abrown/Code/wasmtime/target/x86_64-unknown-linux-gnu/release/differential_spec+0x1865e2e)
    #18 0x56404ca1b8f0 in __rust_try (/home/abrown/Code/wasmtime/target/x86_64-unknown-linux-gnu/release/differential_spec+0x5fe88f0)
    #19 0x56404ca1b07f in LLVMFuzzerTestOneInput (/home/abrown/Code/wasmtime/target/x86_64-unknown-linux-gnu/release/differential_spec+0x5fe807f)
    #20 0x56404ca4ddf1 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/home/abrown/Code/wasmtime/target/x86_64-unknown-linux-gnu/release/differential_spec+0x601adf1)
    #21 0x56404ca52969 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool, bool*) (/home/abrown/Code/wasmtime/target/x86_64-unknown-linux-gnu/release/differential_spec+0x601f969)
    #22 0x56404ca537e8 in fuzzer::Fuzzer::MutateAndTestOne() (/home/abrown/Code/wasmtime/target/x86_64-unknown-linux-gnu/release/differential_spec+0x60207e8)
    #23 0x56404ca55b77 in fuzzer::Fuzzer::Loop(std::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) (/home/abrown/Code/wasmtime/target/x86_64-unknown-linux-gnu/release/differential_spec+0x6022b77)
    #24 0x56404ca297f9 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/home/abrown/Code/wasmtime/target/x86_64-unknown-linux-gnu/release/differential_spec+0x5ff67f9)
    #25 0x564048003992 in main (/home/abrown/Code/wasmtime/target/x86_64-unknown-linux-gnu/release/differential_spec+0x15d0992)
    #26 0x7f4a182b4b74 in __libc_start_main (/lib64/libc.so.6+0x27b74)
    #27 0x564048003b3d in _start (/home/abrown/Code/wasmtime/target/x86_64-unknown-linux-gnu/release/differential_spec+0x15d0b3d)

Versions and Environment

Wasmtime version or commit: https://github.com/abrown/wasmtime/tree/wasm-spec-fuzzing

Operating system: Linux

Architecture: x64

Extra Info

This bug is for a yet-to-be-merged fuzzing oracle (#3124) so it may not apply to released Wasmtime or HEAD. I felt it was better to report it, though, and see if anyone can shed light on what is going on in this failure in case it actually does apply to more than just the fuzzing oracle.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 02 2021 at 16:05):

abrown labeled issue #3135:

Test Case

(module
      (type (;0;) (func))
      (func (;0;) (type 0)
        global.get 0
        i32.eqz
        if  ;; label = @1
          unreachable
        end
        global.get 0
        i32.const 1
        i32.sub
        global.set 0)
      (memory (;0;) 0 1)
      (global (;0;) (mut i32) (i32.const 1000))
      (export "" (func 0))
      (export "\0e" (func 0))
      (data (;0;) (i32.const 249) ""))

Configuration:

Config {
        opt_level: None,
        debug_info: true,
        canonicalize_nans: false,
        interruptable: true,
        consume_fuel: false,
        static_memory_maximum_size: None,
        static_memory_guard_size: None,
        dynamic_memory_guard_size: None,
        guard_before_linear_memory: false,
    }

Steps to Reproduce

I have verified that running Wasmtime directly on this module (cargo +nightly run -- run -g scratch.wat) does not fail so I think the bug is related to how things are configured in the fuzzing oracles.

Expected Results

Instantiate the module while fuzzing.

Actual Results

thread '<unnamed>' panicked at 'Wasmtime can instantiate module: wasm trap: out of bounds memory access', crates/fuzzing/src/oracles.rs:820:10
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
==1092110== ERROR: libFuzzer: deadly signal
    #0 0x564048087231 in __sanitizer_print_stack_trace /rustc/llvm/src/llvm-project/compiler-rt/lib/asan/asan_stack.cpp:86:3
    #1 0x56404ca2b3f8 in fuzzer::PrintStackTrace() (/home/abrown/Code/wasmtime/target/x86_64-unknown-linux-gnu/release/differential_spec+0x5ff83f8)
    #2 0x56404ca4d8b5 in fuzzer::Fuzzer::CrashCallback() (/home/abrown/Code/wasmtime/target/x86_64-unknown-linux-gnu/release/differential_spec+0x601a8b5)
    #3 0x7f4a185bca1f  (/lib64/libpthread.so.0+0x13a1f)
    #4 0x7f4a182ca2a1 in raise (/lib64/libc.so.6+0x3d2a1)
    #5 0x7f4a182b38a3 in abort (/lib64/libc.so.6+0x268a3)
    #6 0x56404cac60f6 in std::sys::unix::abort_internal::h41ede9a5caf8d829 /rustc/b41936b92cd8463020207cb2f62a4247942ef2e4/library/std/src/sys/unix/mod.rs:255:14
    #7 0x564048000a45 in std::process::abort::h1cff6c22924aaee7 /rustc/b41936b92cd8463020207cb2f62a4247942ef2e4/library/std/src/process.rs:1957:5
    #8 0x56404ca1b7bb in libfuzzer_sys::initialize::_$u7b$$u7b$closure$u7d$$u7d$::h9890a57d769a69b1 (/home/abrown/Code/wasmtime/target/x86_64-unknown-linux-gnu/release/differential_spec+0x5fe87bb)
    #9 0x56404cab94f8 in std::panicking::rust_panic_with_hook::h3039e236b6ca482c /rustc/b41936b92cd8463020207cb2f62a4247942ef2e4/library/std/src/panicking.rs:626:17
    #10 0x56404cab8fb6 in std::panicking::begin_panic_handler::_$u7b$$u7b$closure$u7d$$u7d$::h884fbab544ffd91c /rustc/b41936b92cd8463020207cb2f62a4247942ef2e4/library/std/src/panicking.rs:519:13
    #11 0x56404cab54ab in std::sys_common::backtrace::__rust_end_short_backtrace::hdaf2e18ba3d91210 /rustc/b41936b92cd8463020207cb2f62a4247942ef2e4/library/std/src/sys_common/backtrace.rs:141:18
    #12 0x56404cab8f18 in rust_begin_unwind /rustc/b41936b92cd8463020207cb2f62a4247942ef2e4/library/std/src/panicking.rs:515:5
    #13 0x564048003180 in core::panicking::panic_fmt::hcf5f6d96e1dd7099 /rustc/b41936b92cd8463020207cb2f62a4247942ef2e4/library/core/src/panicking.rs:92:14
    #14 0x564048003272 in core::result::unwrap_failed::he898b02f57993c42 /rustc/b41936b92cd8463020207cb2f62a4247942ef2e4/library/core/src/result.rs:1599:5
    #15 0x5640484fb300 in wasmtime_fuzzing::oracles::run_in_wasmtime::h575888b49fa4ed1e (/home/abrown/Code/wasmtime/target/x86_64-unknown-linux-gnu/release/differential_spec+0x1ac8300)
    #16 0x5640484f7de6 in wasmtime_fuzzing::oracles::differential_spec_execution::h74b73ab98332e7b0 (/home/abrown/Code/wasmtime/target/x86_64-unknown-linux-gnu/release/differential_spec+0x1ac4de6)
    #17 0x564048298e2e in rust_fuzzer_test_input (/home/abrown/Code/wasmtime/target/x86_64-unknown-linux-gnu/release/differential_spec+0x1865e2e)
    #18 0x56404ca1b8f0 in __rust_try (/home/abrown/Code/wasmtime/target/x86_64-unknown-linux-gnu/release/differential_spec+0x5fe88f0)
    #19 0x56404ca1b07f in LLVMFuzzerTestOneInput (/home/abrown/Code/wasmtime/target/x86_64-unknown-linux-gnu/release/differential_spec+0x5fe807f)
    #20 0x56404ca4ddf1 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/home/abrown/Code/wasmtime/target/x86_64-unknown-linux-gnu/release/differential_spec+0x601adf1)
    #21 0x56404ca52969 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool, bool*) (/home/abrown/Code/wasmtime/target/x86_64-unknown-linux-gnu/release/differential_spec+0x601f969)
    #22 0x56404ca537e8 in fuzzer::Fuzzer::MutateAndTestOne() (/home/abrown/Code/wasmtime/target/x86_64-unknown-linux-gnu/release/differential_spec+0x60207e8)
    #23 0x56404ca55b77 in fuzzer::Fuzzer::Loop(std::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) (/home/abrown/Code/wasmtime/target/x86_64-unknown-linux-gnu/release/differential_spec+0x6022b77)
    #24 0x56404ca297f9 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/home/abrown/Code/wasmtime/target/x86_64-unknown-linux-gnu/release/differential_spec+0x5ff67f9)
    #25 0x564048003992 in main (/home/abrown/Code/wasmtime/target/x86_64-unknown-linux-gnu/release/differential_spec+0x15d0992)
    #26 0x7f4a182b4b74 in __libc_start_main (/lib64/libc.so.6+0x27b74)
    #27 0x564048003b3d in _start (/home/abrown/Code/wasmtime/target/x86_64-unknown-linux-gnu/release/differential_spec+0x15d0b3d)

Versions and Environment

Wasmtime version or commit: https://github.com/abrown/wasmtime/tree/wasm-spec-fuzzing

Operating system: Linux

Architecture: x64

Extra Info

This bug is for a yet-to-be-merged fuzzing oracle (#3124) so it may not apply to released Wasmtime or HEAD. I felt it was better to report it, though, and see if anyone can shed light on what is going on in this failure in case it actually does apply to more than just the fuzzing oracle.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 02 2021 at 16:15):

alexcrichton commented on issue #3135:

Looking at that module the "faulty" bit appears to be:

(module
      (memory (;0;) 0 1)
      (data (;0;) (i32.const 249) ""))

where a data segment, which is empty, is being written to memory where memory has size 0 at the beginning. I instantiated this locally with wasmtime foo.wat and it gave a trap (as expected).

Double-checking the spec instantiation delegates data segment initialization to memory.init which is specified to still trap even with zero-length copies, so I think Wasmtime has the right behavior here?

Is this something that the spec interpreter doesn't trap on but Wasmtime traps on?

view this post on Zulip Wasmtime GitHub notifications bot (Aug 02 2021 at 16:17):

alexcrichton commented on issue #3135:

er disregard all that, I reread and things make more sense now

view this post on Zulip Wasmtime GitHub notifications bot (Aug 02 2021 at 16:22):

alexcrichton commented on issue #3135:

er sorry for the spam, I'm actually extra confused now. On your branch the oracle is configured to panic if instantiation fails, but instantiation is expected to fail here, so I think that's a bug in the oracle where it should allow instantiation to fail and then assert that the spec interpreter also fails instantiation.

You then also say, though, that cargo +nightly run -- run -g scratch.wat does not fail, but testing locally myself shows that it does indeed fail instantiation. Are you sure that scratch.wat is the right file? (the one in this issue?)

view this post on Zulip Wasmtime GitHub notifications bot (Aug 02 2021 at 16:37):

abrown commented on issue #3135:

Ok, yeah, this makes more sense now: indeed I copied in the wrong thing to scratch.wat and when I do copy the right thing I see the expected failure: wasm trap: out of bounds memory access.

So this snippet should indeed fail but not fail with a panic, right? I'll make it a regular Result error instead. What is interesting here is that the instantiation code I use is the same as that of the differential_wasmi oracle (https://github.com/bytecodealliance/wasmtime/blob/main/crates/fuzzing/src/oracles.rs#L635-L638) so I'm surprised that we don't see a similar crash there? Or do we not run that fuzz target on oss-fuzz?

view this post on Zulip Wasmtime GitHub notifications bot (Aug 02 2021 at 16:40):

abrown commented on issue #3135:

And actually thinking about it more, it seems like there should be some way to distinguish between "we failed instantiation because something broke in Wasmtime" and "we failed instantiation because the input WebAssembly is invalid," right?

view this post on Zulip Wasmtime GitHub notifications bot (Aug 02 2021 at 16:48):

alexcrichton commented on issue #3135:

I believe the target is run on oss-fuzz, and I think the failure to instantiate is handled here where we instantiate with wasmi first and if that fails we don't even hit wasmtime.

Ideally, though, for the spec interpreter we'd separate the instantiate/invoke steps to ensure that wasmtime has the same behavior.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 02 2021 at 17:08):

abrown commented on issue #3135:

Ok, sounds like this is resolved... thanks!

view this post on Zulip Wasmtime GitHub notifications bot (Aug 02 2021 at 17:08):

abrown closed issue #3135:

Test Case

(module
      (type (;0;) (func))
      (func (;0;) (type 0)
        global.get 0
        i32.eqz
        if  ;; label = @1
          unreachable
        end
        global.get 0
        i32.const 1
        i32.sub
        global.set 0)
      (memory (;0;) 0 1)
      (global (;0;) (mut i32) (i32.const 1000))
      (export "" (func 0))
      (export "\0e" (func 0))
      (data (;0;) (i32.const 249) ""))

Configuration:

Config {
        opt_level: None,
        debug_info: true,
        canonicalize_nans: false,
        interruptable: true,
        consume_fuel: false,
        static_memory_maximum_size: None,
        static_memory_guard_size: None,
        dynamic_memory_guard_size: None,
        guard_before_linear_memory: false,
    }

Steps to Reproduce

I have verified that running Wasmtime directly on this module (cargo +nightly run -- run -g scratch.wat) does not fail so I think the bug is related to how things are configured in the fuzzing oracles.

Expected Results

Instantiate the module while fuzzing.

Actual Results

thread '<unnamed>' panicked at 'Wasmtime can instantiate module: wasm trap: out of bounds memory access', crates/fuzzing/src/oracles.rs:820:10
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
==1092110== ERROR: libFuzzer: deadly signal
    #0 0x564048087231 in __sanitizer_print_stack_trace /rustc/llvm/src/llvm-project/compiler-rt/lib/asan/asan_stack.cpp:86:3
    #1 0x56404ca2b3f8 in fuzzer::PrintStackTrace() (/home/abrown/Code/wasmtime/target/x86_64-unknown-linux-gnu/release/differential_spec+0x5ff83f8)
    #2 0x56404ca4d8b5 in fuzzer::Fuzzer::CrashCallback() (/home/abrown/Code/wasmtime/target/x86_64-unknown-linux-gnu/release/differential_spec+0x601a8b5)
    #3 0x7f4a185bca1f  (/lib64/libpthread.so.0+0x13a1f)
    #4 0x7f4a182ca2a1 in raise (/lib64/libc.so.6+0x3d2a1)
    #5 0x7f4a182b38a3 in abort (/lib64/libc.so.6+0x268a3)
    #6 0x56404cac60f6 in std::sys::unix::abort_internal::h41ede9a5caf8d829 /rustc/b41936b92cd8463020207cb2f62a4247942ef2e4/library/std/src/sys/unix/mod.rs:255:14
    #7 0x564048000a45 in std::process::abort::h1cff6c22924aaee7 /rustc/b41936b92cd8463020207cb2f62a4247942ef2e4/library/std/src/process.rs:1957:5
    #8 0x56404ca1b7bb in libfuzzer_sys::initialize::_$u7b$$u7b$closure$u7d$$u7d$::h9890a57d769a69b1 (/home/abrown/Code/wasmtime/target/x86_64-unknown-linux-gnu/release/differential_spec+0x5fe87bb)
    #9 0x56404cab94f8 in std::panicking::rust_panic_with_hook::h3039e236b6ca482c /rustc/b41936b92cd8463020207cb2f62a4247942ef2e4/library/std/src/panicking.rs:626:17
    #10 0x56404cab8fb6 in std::panicking::begin_panic_handler::_$u7b$$u7b$closure$u7d$$u7d$::h884fbab544ffd91c /rustc/b41936b92cd8463020207cb2f62a4247942ef2e4/library/std/src/panicking.rs:519:13
    #11 0x56404cab54ab in std::sys_common::backtrace::__rust_end_short_backtrace::hdaf2e18ba3d91210 /rustc/b41936b92cd8463020207cb2f62a4247942ef2e4/library/std/src/sys_common/backtrace.rs:141:18
    #12 0x56404cab8f18 in rust_begin_unwind /rustc/b41936b92cd8463020207cb2f62a4247942ef2e4/library/std/src/panicking.rs:515:5
    #13 0x564048003180 in core::panicking::panic_fmt::hcf5f6d96e1dd7099 /rustc/b41936b92cd8463020207cb2f62a4247942ef2e4/library/core/src/panicking.rs:92:14
    #14 0x564048003272 in core::result::unwrap_failed::he898b02f57993c42 /rustc/b41936b92cd8463020207cb2f62a4247942ef2e4/library/core/src/result.rs:1599:5
    #15 0x5640484fb300 in wasmtime_fuzzing::oracles::run_in_wasmtime::h575888b49fa4ed1e (/home/abrown/Code/wasmtime/target/x86_64-unknown-linux-gnu/release/differential_spec+0x1ac8300)
    #16 0x5640484f7de6 in wasmtime_fuzzing::oracles::differential_spec_execution::h74b73ab98332e7b0 (/home/abrown/Code/wasmtime/target/x86_64-unknown-linux-gnu/release/differential_spec+0x1ac4de6)
    #17 0x564048298e2e in rust_fuzzer_test_input (/home/abrown/Code/wasmtime/target/x86_64-unknown-linux-gnu/release/differential_spec+0x1865e2e)
    #18 0x56404ca1b8f0 in __rust_try (/home/abrown/Code/wasmtime/target/x86_64-unknown-linux-gnu/release/differential_spec+0x5fe88f0)
    #19 0x56404ca1b07f in LLVMFuzzerTestOneInput (/home/abrown/Code/wasmtime/target/x86_64-unknown-linux-gnu/release/differential_spec+0x5fe807f)
    #20 0x56404ca4ddf1 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/home/abrown/Code/wasmtime/target/x86_64-unknown-linux-gnu/release/differential_spec+0x601adf1)
    #21 0x56404ca52969 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool, bool*) (/home/abrown/Code/wasmtime/target/x86_64-unknown-linux-gnu/release/differential_spec+0x601f969)
    #22 0x56404ca537e8 in fuzzer::Fuzzer::MutateAndTestOne() (/home/abrown/Code/wasmtime/target/x86_64-unknown-linux-gnu/release/differential_spec+0x60207e8)
    #23 0x56404ca55b77 in fuzzer::Fuzzer::Loop(std::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) (/home/abrown/Code/wasmtime/target/x86_64-unknown-linux-gnu/release/differential_spec+0x6022b77)
    #24 0x56404ca297f9 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/home/abrown/Code/wasmtime/target/x86_64-unknown-linux-gnu/release/differential_spec+0x5ff67f9)
    #25 0x564048003992 in main (/home/abrown/Code/wasmtime/target/x86_64-unknown-linux-gnu/release/differential_spec+0x15d0992)
    #26 0x7f4a182b4b74 in __libc_start_main (/lib64/libc.so.6+0x27b74)
    #27 0x564048003b3d in _start (/home/abrown/Code/wasmtime/target/x86_64-unknown-linux-gnu/release/differential_spec+0x15d0b3d)

Versions and Environment

Wasmtime version or commit: https://github.com/abrown/wasmtime/tree/wasm-spec-fuzzing

Operating system: Linux

Architecture: x64

Extra Info

This bug is for a yet-to-be-merged fuzzing oracle (#3124) so it may not apply to released Wasmtime or HEAD. I felt it was better to report it, though, and see if anyone can shed light on what is going on in this failure in case it actually does apply to more than just the fuzzing oracle.

Last updated: Oct 23 2024 at 20:03 UTC