Created attachment 166044 [details] Wasm module to reproduce the error SUMMARY My compiler is producing very unoptimzed wasm and I use WAMR (from Intel) to embed the code produced in my (limited) test suite. Using memcheck on it I have an unrecognized instruction. Using this online disassembler (https://defuse.ca/online-x86-assembler.htm#disassembly2), I was able to see this was the instruction wrgsbase which I should have disabled compiling WAMR here (https://github.com/bytecodealliance/wasm-micro-runtime/blob/169e1648156d008825831fb00d5e3acbe021b480/core/shared/platform/linux/platform_internal.h#L72). *** NOTE: If you are reporting a crash, please try to attach a backtrace with debug symbols. See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** BACKTRACE root@04cd636dc288:/workspaces/dmit# valgrind ./bin/test/test -tc=gen_run ==1737== Memcheck, a memory error detector ==1737== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==1737== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info ==1737== Command: ./bin/test/test -tc=gen_run ==1737== [doctest] doctest version is "2.4.9" [doctest] run with "--help" for options 0000CLK0 0s 46m 150u Make archive 0001CLK0 0s 60m 112u Linking ==1737== Warning: client switching stacks? SP change: 0x1ffe802890 --> 0x1ffeffee50 ==1737== to suppress, use: --max-stackframe=8373696 or greater 0002CLK0 0s 23m 493u Runtime creation ==1737== Warning: set address range perms: large range [0x59c87000, 0x259e87000) (noaccess) vex amd64->IR: unhandled instruction bytes: 0xF3 0x48 0xF 0xAE 0xD8 0x41 0x80 0x3C 0x24 0x0 vex amd64->IR: REX=1 REX.W=1 REX.R=0 REX.X=0 REX.B=0 vex amd64->IR: VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=0F vex amd64->IR: PFX.66=0 PFX.F2=0 PFX.F3=1 ==1737== valgrind: Unrecognised instruction at address 0x6124dd. ==1737== at 0x6124DD: wasm_interp_call_wasm (in /workspaces/dmit/bin/test/test) ==1737== by 0x60C046: call_wasm_with_hw_bound_check (in /workspaces/dmit/bin/test/test) ==1737== by 0x60C826: wasm_call_function (in /workspaces/dmit/bin/test/test) ==1737== by 0x60DC71: wasm_instantiate (in /workspaces/dmit/bin/test/test) ==1737== by 0x5E7D3A: wasm_runtime_instantiate (in /workspaces/dmit/bin/test/test) ==1737== by 0x381060: wamr::Runtime::makeModuleInstance(unsigned char*, unsigned int) (wamr.cpp:41) ==1737== by 0x38121C: wamr::Runtime::makeModuleInstance(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&) (wamr.cpp:74) ==1737== by 0x2D40CB: DOCTEST_ANON_FUNC_5() (dmit_gen.cpp:173) ==1737== by 0x5C6B43: doctest::Context::run() (in /workspaces/dmit/bin/test/test) ==1737== by 0x5C7AB2: main (in /workspaces/dmit/bin/test/test) STEPS TO REPRODUCE 1. My draft of compiler has a very unpolished dev env but it is probably easier to reproduce clone it from here: https://github.com/matovitch/dmit 2. Use vscode which should propose to install the devcontainer extension 3. In a terminal do: . env/env.sh make valgrind bin/test/test -tc=gen_run Note I have the version 3.18.1 on the docker image but I reproduce the issue with the 3.22.0. OBSERVED RESULT See backtrace above. EXPECTED RESULT Hopefully no errors and no leak (this is the case for the tests without WAMR). I have a coroutine scheduler which is doing stack switching but valgrind is informed if you use the flag: # Register coroutine stack for valgrind CONFIG_IS_USING_VALGRIND=y In bin/tup.config SOFTWARE/OS VERSIONS Windows: 10.0.19045 Build 19045 WSL: Ubuntu 22.04 LTS ADDITIONAL INFORMATION Do not hesitate to contact me if you have trouble reproducing it. I've added the wasm code. If you run it with iwasm from WAMR project I would expect a similar result.
I forgot you have to do tup init before calling make. You can also simply do tup init && tup. And you can use github's codespace if you don't want to install or download anything although their atom cores are slow to compile.
I don't think that any of the Valgrind developers use stuff like wasm or containers. And as a rule you will get better results either on bare metal or using full virtualization VM (vmware, virtualbox etc). Do you know what this environment is using GS for? As a rule on amd64 Valgrind makes very little use of the segment registers - they are almost never needed for running compiled C and C++ code on bare metal OSes.
I am on holidays without access to a computer this week (writing it on my phone). About the use of the GS register the wamr jit (ab)use it for the loads and stores into the wasm linear memory: https://github.com/bytecodealliance/wasm-micro-runtime/blob/169e1648156d008825831fb00d5e3acbe021b480/product-mini/platforms/posix/main.c#L65 Note that I fixed the latest docker image disabling the use of this register in the libvmcore so you won't have the issue with the latest code. It seems a patch exists for valgrind to support the fsgsbase instructions: https://davejingtian.org/2018/07/07/hacking-valgrind/