Bug 481733

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.