Stream: git-wasmtime

Topic: wasmtime / issue #6326 Valgrind errors for `Func` 175+ re...

view this post on Zulip Wasmtime GitHub notifications bot (May 02 2023 at 14:13):

jbourassa opened issue #6326:

Test Case

This repo: https://github.com/jbourassa/wasmtime-results-valgrind-report

The repro case is a host-defined wasmtime::Func that returns 200 results:

use wasmtime::{AsContextMut, Engine, Func, Store};
const RESULTS_COUNT: i32 = 200;

fn main() -> wasmtime::Result<()> {
    let engine = Engine::default();
    let mut store = Store::new(&engine, ());
    let result_type: Vec<_> = (0..RESULTS_COUNT).map(|_| wasmtime::ValType::I32).collect();
    let func_type = wasmtime::FuncType::new([], result_type);
    let func = Func::new(&mut store, func_type.clone(), |_, _, results| {
        results
            .iter_mut()
            .for_each(|val| *val = wasmtime::Val::I32(1));
        Ok(())
    });
    let mut results = vec![wasmtime::Val::null(); func_type.results().len()];
    func.call(store.as_context_mut(), &[], &mut results)?;
    Ok(())
}

Steps to Reproduce

  1. Clone the repo
  2. Run the executable with valgrind: cargo build && valgrind target/debug/many-results

Result, Version, Environment

Wasmtime version: v8.0.1 (but also appeared in 7.0 and likely earlier versions)

Valgrind version: 3.21.0 (latest, but also reproducible with 3.18.1)

On aarch64 (Linux running on an ARM-based Mac), Ubuntu 22.10, the valgrind report is:

ARM64 front end: load_store
disInstr(arm64): unhandled instruction 0xB830EBFF
disInstr(arm64): 1011'1000 0011'0000 1110'1011 1111'1111
==25125== valgrind: Unrecognised instruction at address 0x4f6fc2c.
==25125==    at 0x4F6FC2C: ???
==25125== Your program just tried to execute an instruction that Valgrind
==25125== did not recognise.  There are two possible reasons for this.
==25125== 1. Your program has a bug and erroneously jumped to a non-code
==25125==    location.  If you are running Memcheck and you just saw a
==25125==    warning about a bad jump, it's probably your program's fault.
==25125== 2. The instruction is legitimate but Valgrind doesn't handle it,
==25125==    i.e. it's Valgrind's fault.  If you think this is the case or
==25125==    you are not sure, please let us know and we'll try to fix it.
==25125== Either way, Valgrind will now raise a SIGILL signal which will
==25125== probably kill your program.

On x86, Ubuntu 22.04.2 LTS, the valgrind report is:

=58680== Invalid write of size 4
==58680==    at 0x4F973B4: ???
==58680==    by 0x4F96047: ???
==58680==    by 0x2032D3: wasmtime::func::Func::call_unchecked_raw::{{closure}} (func.rs:900)
==58680==    by 0x20B0BA: wasmtime_runtime::traphandlers::catch_traps::call_closure (traphandlers.rs:243)
==58680==    by 0xAA669F: wasmtime_setjmp (helpers.c:55)
==58680==    by 0x20B415: wasmtime_runtime::traphandlers::catch_traps::{{closure}} (traphandlers.rs:225)
==58680==    by 0x20B441: wasmtime_runtime::traphandlers::<impl wasmtime_runtime::traphandlers::call_thread_state::CallThreadState>::with::{{closure}} (traphandlers.rs:409)
==58680==    by 0x208462: wasmtime_runtime::traphandlers::tls::set (traphandlers.rs:684)
==58680==    by 0x214F1D: wasmtime_runtime::traphandlers::<impl wasmtime_runtime::traphandlers::call_thread_state::CallThreadState>::with (traphandlers.rs:409)
==58680==    by 0x20B1BB: wasmtime_runtime::traphandlers::catch_traps (traphandlers.rs:224)
==58680==    by 0x202C5E: wasmtime::func::invoke_wasm_and_catch_traps (func.rs:1306)
==58680==    by 0x20324C: wasmtime::func::Func::call_unchecked_raw (func.rs:898)
==58680==  Address 0x1ffeffc580 is on thread 1's stack
==58680==  4096 bytes below stack pointer
==58680==
==58680== Invalid write of size 4
==58680==    at 0x4F973BB: ???
==58680==    by 0x4F96047: ???
==58680==    by 0x2032D3: wasmtime::func::Func::call_unchecked_raw::{{closure}} (func.rs:900)
==58680==    by 0x20B0BA: wasmtime_runtime::traphandlers::catch_traps::call_closure (traphandlers.rs:243)
==58680==    by 0xAA669F: wasmtime_setjmp (helpers.c:55)
==58680==    by 0x20B415: wasmtime_runtime::traphandlers::catch_traps::{{closure}} (traphandlers.rs:225)
==58680==    by 0x20B441: wasmtime_runtime::traphandlers::<impl wasmtime_runtime::traphandlers::call_thread_state::CallThreadState>::with::{{closure}} (traphandlers.rs:409)
==58680==    by 0x208462: wasmtime_runtime::traphandlers::tls::set (traphandlers.rs:684)
==58680==    by 0x214F1D: wasmtime_runtime::traphandlers::<impl wasmtime_runtime::traphandlers::call_thread_state::CallThreadState>::with (traphandlers.rs:409)
==58680==    by 0x20B1BB: wasmtime_runtime::traphandlers::catch_traps (traphandlers.rs:224)
==58680==    by 0x202C5E: wasmtime::func::invoke_wasm_and_catch_traps (func.rs:1306)
==58680==    by 0x20324C: wasmtime::func::Func::call_unchecked_raw (func.rs:898)
==58680==  Address 0x1ffeffb580 is on thread 1's stack
==58680==  8192 bytes below stack pointer

Extra Info

I don't know if it's an actual bug, but figured I should report it. Feel free to close it if it's a false-positive.

view this post on Zulip Wasmtime GitHub notifications bot (May 02 2023 at 14:13):

jbourassa labeled issue #6326:

Test Case

This repo: https://github.com/jbourassa/wasmtime-results-valgrind-report

The repro case is a host-defined wasmtime::Func that returns 200 results:

use wasmtime::{AsContextMut, Engine, Func, Store};
const RESULTS_COUNT: i32 = 200;

fn main() -> wasmtime::Result<()> {
    let engine = Engine::default();
    let mut store = Store::new(&engine, ());
    let result_type: Vec<_> = (0..RESULTS_COUNT).map(|_| wasmtime::ValType::I32).collect();
    let func_type = wasmtime::FuncType::new([], result_type);
    let func = Func::new(&mut store, func_type.clone(), |_, _, results| {
        results
            .iter_mut()
            .for_each(|val| *val = wasmtime::Val::I32(1));
        Ok(())
    });
    let mut results = vec![wasmtime::Val::null(); func_type.results().len()];
    func.call(store.as_context_mut(), &[], &mut results)?;
    Ok(())
}

Steps to Reproduce

  1. Clone the repo
  2. Run the executable with valgrind: cargo build && valgrind target/debug/many-results

Result, Version, Environment

Wasmtime version: v8.0.1 (but also appeared in 7.0 and likely earlier versions)

Valgrind version: 3.21.0 (latest, but also reproducible with 3.18.1)

On aarch64 (Linux running on an ARM-based Mac), Ubuntu 22.10, the valgrind report is:

ARM64 front end: load_store
disInstr(arm64): unhandled instruction 0xB830EBFF
disInstr(arm64): 1011'1000 0011'0000 1110'1011 1111'1111
==25125== valgrind: Unrecognised instruction at address 0x4f6fc2c.
==25125==    at 0x4F6FC2C: ???
==25125== Your program just tried to execute an instruction that Valgrind
==25125== did not recognise.  There are two possible reasons for this.
==25125== 1. Your program has a bug and erroneously jumped to a non-code
==25125==    location.  If you are running Memcheck and you just saw a
==25125==    warning about a bad jump, it's probably your program's fault.
==25125== 2. The instruction is legitimate but Valgrind doesn't handle it,
==25125==    i.e. it's Valgrind's fault.  If you think this is the case or
==25125==    you are not sure, please let us know and we'll try to fix it.
==25125== Either way, Valgrind will now raise a SIGILL signal which will
==25125== probably kill your program.

On x86, Ubuntu 22.04.2 LTS, the valgrind report is:

=58680== Invalid write of size 4
==58680==    at 0x4F973B4: ???
==58680==    by 0x4F96047: ???
==58680==    by 0x2032D3: wasmtime::func::Func::call_unchecked_raw::{{closure}} (func.rs:900)
==58680==    by 0x20B0BA: wasmtime_runtime::traphandlers::catch_traps::call_closure (traphandlers.rs:243)
==58680==    by 0xAA669F: wasmtime_setjmp (helpers.c:55)
==58680==    by 0x20B415: wasmtime_runtime::traphandlers::catch_traps::{{closure}} (traphandlers.rs:225)
==58680==    by 0x20B441: wasmtime_runtime::traphandlers::<impl wasmtime_runtime::traphandlers::call_thread_state::CallThreadState>::with::{{closure}} (traphandlers.rs:409)
==58680==    by 0x208462: wasmtime_runtime::traphandlers::tls::set (traphandlers.rs:684)
==58680==    by 0x214F1D: wasmtime_runtime::traphandlers::<impl wasmtime_runtime::traphandlers::call_thread_state::CallThreadState>::with (traphandlers.rs:409)
==58680==    by 0x20B1BB: wasmtime_runtime::traphandlers::catch_traps (traphandlers.rs:224)
==58680==    by 0x202C5E: wasmtime::func::invoke_wasm_and_catch_traps (func.rs:1306)
==58680==    by 0x20324C: wasmtime::func::Func::call_unchecked_raw (func.rs:898)
==58680==  Address 0x1ffeffc580 is on thread 1's stack
==58680==  4096 bytes below stack pointer
==58680==
==58680== Invalid write of size 4
==58680==    at 0x4F973BB: ???
==58680==    by 0x4F96047: ???
==58680==    by 0x2032D3: wasmtime::func::Func::call_unchecked_raw::{{closure}} (func.rs:900)
==58680==    by 0x20B0BA: wasmtime_runtime::traphandlers::catch_traps::call_closure (traphandlers.rs:243)
==58680==    by 0xAA669F: wasmtime_setjmp (helpers.c:55)
==58680==    by 0x20B415: wasmtime_runtime::traphandlers::catch_traps::{{closure}} (traphandlers.rs:225)
==58680==    by 0x20B441: wasmtime_runtime::traphandlers::<impl wasmtime_runtime::traphandlers::call_thread_state::CallThreadState>::with::{{closure}} (traphandlers.rs:409)
==58680==    by 0x208462: wasmtime_runtime::traphandlers::tls::set (traphandlers.rs:684)
==58680==    by 0x214F1D: wasmtime_runtime::traphandlers::<impl wasmtime_runtime::traphandlers::call_thread_state::CallThreadState>::with (traphandlers.rs:409)
==58680==    by 0x20B1BB: wasmtime_runtime::traphandlers::catch_traps (traphandlers.rs:224)
==58680==    by 0x202C5E: wasmtime::func::invoke_wasm_and_catch_traps (func.rs:1306)
==58680==    by 0x20324C: wasmtime::func::Func::call_unchecked_raw (func.rs:898)
==58680==  Address 0x1ffeffb580 is on thread 1's stack
==58680==  8192 bytes below stack pointer

Extra Info

I don't know if it's an actual bug, but figured I should report it. Feel free to close it if it's a false-positive.

view this post on Zulip Wasmtime GitHub notifications bot (May 02 2023 at 19:58):

jameysharp commented on issue #6326:

Here's a quick first look at this issue, not the final word on anything.

I'm guessing the issue on aarch64 is that we're using a real instruction that is unimplemented in that version of valgrind, which would mean that one is not our bug. But I haven't verified that and could certainly be wrong.

As for the invalid writes on x86, that could be our bug, but I'm not sure. The relevant code changed a lot last week in #6262, after the 8.0 release, so I'm curious if it's still reproducible on current git main. Do you have time to give that a try?

view this post on Zulip Wasmtime GitHub notifications bot (May 02 2023 at 21:05):

jbourassa commented on issue #6326:

Do you have time to give that a try?

valgrind reports are gone on main, both for aarch64 and x86 :tada:. I guess we can close this issue.

Thanks Jamey!

view this post on Zulip Wasmtime GitHub notifications bot (May 02 2023 at 21:05):

jbourassa closed issue #6326:

Test Case

This repo: https://github.com/jbourassa/wasmtime-results-valgrind-report

The repro case is a host-defined wasmtime::Func that returns 200 results:

use wasmtime::{AsContextMut, Engine, Func, Store};
const RESULTS_COUNT: i32 = 200;

fn main() -> wasmtime::Result<()> {
    let engine = Engine::default();
    let mut store = Store::new(&engine, ());
    let result_type: Vec<_> = (0..RESULTS_COUNT).map(|_| wasmtime::ValType::I32).collect();
    let func_type = wasmtime::FuncType::new([], result_type);
    let func = Func::new(&mut store, func_type.clone(), |_, _, results| {
        results
            .iter_mut()
            .for_each(|val| *val = wasmtime::Val::I32(1));
        Ok(())
    });
    let mut results = vec![wasmtime::Val::null(); func_type.results().len()];
    func.call(store.as_context_mut(), &[], &mut results)?;
    Ok(())
}

Steps to Reproduce

  1. Clone the repo
  2. Run the executable with valgrind: cargo build && valgrind target/debug/many-results

Result, Version, Environment

Wasmtime version: v8.0.1 (but also appeared in 7.0 and likely earlier versions)

Valgrind version: 3.21.0 (latest, but also reproducible with 3.18.1)

On aarch64 (Linux running on an ARM-based Mac), Ubuntu 22.10, the valgrind report is:

ARM64 front end: load_store
disInstr(arm64): unhandled instruction 0xB830EBFF
disInstr(arm64): 1011'1000 0011'0000 1110'1011 1111'1111
==25125== valgrind: Unrecognised instruction at address 0x4f6fc2c.
==25125==    at 0x4F6FC2C: ???
==25125== Your program just tried to execute an instruction that Valgrind
==25125== did not recognise.  There are two possible reasons for this.
==25125== 1. Your program has a bug and erroneously jumped to a non-code
==25125==    location.  If you are running Memcheck and you just saw a
==25125==    warning about a bad jump, it's probably your program's fault.
==25125== 2. The instruction is legitimate but Valgrind doesn't handle it,
==25125==    i.e. it's Valgrind's fault.  If you think this is the case or
==25125==    you are not sure, please let us know and we'll try to fix it.
==25125== Either way, Valgrind will now raise a SIGILL signal which will
==25125== probably kill your program.

On x86, Ubuntu 22.04.2 LTS, the valgrind report is:

=58680== Invalid write of size 4
==58680==    at 0x4F973B4: ???
==58680==    by 0x4F96047: ???
==58680==    by 0x2032D3: wasmtime::func::Func::call_unchecked_raw::{{closure}} (func.rs:900)
==58680==    by 0x20B0BA: wasmtime_runtime::traphandlers::catch_traps::call_closure (traphandlers.rs:243)
==58680==    by 0xAA669F: wasmtime_setjmp (helpers.c:55)
==58680==    by 0x20B415: wasmtime_runtime::traphandlers::catch_traps::{{closure}} (traphandlers.rs:225)
==58680==    by 0x20B441: wasmtime_runtime::traphandlers::<impl wasmtime_runtime::traphandlers::call_thread_state::CallThreadState>::with::{{closure}} (traphandlers.rs:409)
==58680==    by 0x208462: wasmtime_runtime::traphandlers::tls::set (traphandlers.rs:684)
==58680==    by 0x214F1D: wasmtime_runtime::traphandlers::<impl wasmtime_runtime::traphandlers::call_thread_state::CallThreadState>::with (traphandlers.rs:409)
==58680==    by 0x20B1BB: wasmtime_runtime::traphandlers::catch_traps (traphandlers.rs:224)
==58680==    by 0x202C5E: wasmtime::func::invoke_wasm_and_catch_traps (func.rs:1306)
==58680==    by 0x20324C: wasmtime::func::Func::call_unchecked_raw (func.rs:898)
==58680==  Address 0x1ffeffc580 is on thread 1's stack
==58680==  4096 bytes below stack pointer
==58680==
==58680== Invalid write of size 4
==58680==    at 0x4F973BB: ???
==58680==    by 0x4F96047: ???
==58680==    by 0x2032D3: wasmtime::func::Func::call_unchecked_raw::{{closure}} (func.rs:900)
==58680==    by 0x20B0BA: wasmtime_runtime::traphandlers::catch_traps::call_closure (traphandlers.rs:243)
==58680==    by 0xAA669F: wasmtime_setjmp (helpers.c:55)
==58680==    by 0x20B415: wasmtime_runtime::traphandlers::catch_traps::{{closure}} (traphandlers.rs:225)
==58680==    by 0x20B441: wasmtime_runtime::traphandlers::<impl wasmtime_runtime::traphandlers::call_thread_state::CallThreadState>::with::{{closure}} (traphandlers.rs:409)
==58680==    by 0x208462: wasmtime_runtime::traphandlers::tls::set (traphandlers.rs:684)
==58680==    by 0x214F1D: wasmtime_runtime::traphandlers::<impl wasmtime_runtime::traphandlers::call_thread_state::CallThreadState>::with (traphandlers.rs:409)
==58680==    by 0x20B1BB: wasmtime_runtime::traphandlers::catch_traps (traphandlers.rs:224)
==58680==    by 0x202C5E: wasmtime::func::invoke_wasm_and_catch_traps (func.rs:1306)
==58680==    by 0x20324C: wasmtime::func::Func::call_unchecked_raw (func.rs:898)
==58680==  Address 0x1ffeffb580 is on thread 1's stack
==58680==  8192 bytes below stack pointer

Extra Info

I don't know if it's an actual bug, but figured I should report it. Feel free to close it if it's a false-positive.

Last updated: Nov 22 2024 at 16:03 UTC