https://bugs.kde.org/show_bug.cgi?id=481733
Bug ID: 481733
Summary: Unrecognized amd64 instruction wrgsbase
Classification: Developer tools
Product: valgrind
Version: 3.22.0
Platform: Ubuntu
OS: Microsoft Windows
Status: REPORTED
Severity: normal
Priority: NOR
Component: memcheck
Assignee: jsew...@acm.org
Reporter: camille.bru...@laposte.net
Target Milestone: ---
Created attachment 166044
--> https://bugs.kde.org/attachment.cgi?id=166044&action=edit
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.
--
You are receiving this mail because:
You are watching all bug changes.
