Running DRD or Helgrind on test case helgrind/tests/tc12_rwl_trivial compiled in 32-bit mode (X86) produces the following crash: $ ./vg-in-place --tool=helgrind helgrind/tests/tc12_rwl_trivial ==29388== Helgrind, a thread error detector ==29388== Copyright (C) 2007-2017, and GNU GPL'd, by OpenWorks LLP et al. ==29388== Using Valgrind-3.13.0.SVN and LibVEX; rerun with -h for copyright info ==29388== Command: helgrind/tests/tc12_rwl_trivial ==29388== ==29388== ---Thread-Announcement------------------------------------------ ==29388== ==29388== Thread #1 is the program's root thread ==29388== ==29388== ---------------------------------------------------------------- ==29388== ==29388== Thread #1 unlocked a not-locked lock at 0xFEA5ADEC ==29388== at 0x48333AB: pthread_rwlock_unlock_WRK (hg_intercepts.c:2540) ==29388== by 0x4834D7C: pthread_rwlock_unlock (hg_intercepts.c:2559) ==29388== by 0x10891F: safe_pthread_rwlock_unlock (safe-pthread.h:58) ==29388== by 0x108AF9: main (tc12_rwl_trivial.c:29) ==29388== Lock at 0xFEA5ADEC was first observed ==29388== at 0x4832D45: pthread_rwlock_init_WRK (hg_intercepts.c:2027) ==29388== by 0x4834D2E: pthread_rwlock_init (hg_intercepts.c:2042) ==29388== by 0x10898D: main (tc12_rwl_trivial.c:18) ==29388== Address 0xfea5adec is on thread #1's stack ==29388== in frame #3, created by main (tc12_rwl_trivial.c:14) ==29388== ==29388== vex: the `impossible' happened: disAMode(x86): not an addr! vex storage: T total 32739272 bytes allocated vex storage: P total 384 bytes allocated valgrind: the 'impossible' happened: LibVEX called failure_exit(). host stacktrace: ==29388== at 0x5802918B: show_sched_status_wrk (m_libcassert.c:355) ==29388== by 0x580292BD: report_and_quit (m_libcassert.c:426) ==29388== by 0x5802946C: panic (m_libcassert.c:502) ==29388== by 0x5802946C: vgPlain_core_panic_at (m_libcassert.c:507) ==29388== by 0x5802948A: vgPlain_core_panic (m_libcassert.c:512) ==29388== by 0x580449FC: failure_exit (m_translate.c:740) ==29388== by 0x581062F3: vpanic (main_util.c:231) ==29388== by 0x5812886B: disAMode (guest_x86_toIR.c:1564) ==29388== by 0x58148B0C: disInstr_X86_WRK (guest_x86_toIR.c:15322) ==29388== by 0x5814A3A1: disInstr_X86 (guest_x86_toIR.c:15456) ==29388== by 0x5811D570: bb_to_IR (guest_generic_bb_to_IR.c:365) ==29388== by 0x5810370F: LibVEX_FrontEnd (main_main.c:558) ==29388== by 0x58103F42: LibVEX_Translate (main_main.c:1173) ==29388== by 0x580472B7: vgPlain_translate (m_translate.c:1791) ==29388== by 0x58082558: handle_chain_me (scheduler.c:1084) ==29388== by 0x58084257: vgPlain_scheduler (scheduler.c:1428) ==29388== by 0x58094FA7: thread_wrapper (syswrap-linux.c:103) ==29388== by 0x58094FA7: run_a_thread_NORETURN (syswrap-linux.c:156) sched status: running_tid=1 Thread 1: status = VgTs_Runnable (lwpid 29388) ==29388== at 0x4873818: _xend (pthread_rwlock_unlock.c:38) ==29388== by 0x4873818: pthread_rwlock_unlock (pthread_rwlock_unlock.c:38) ==29388== by 0x48333DA: pthread_rwlock_unlock_WRK (hg_intercepts.c:2543) ==29388== by 0x4834D7C: pthread_rwlock_unlock (hg_intercepts.c:2559) ==29388== by 0x10891F: safe_pthread_rwlock_unlock (safe-pthread.h:58) ==29388== by 0x108AF9: main (tc12_rwl_trivial.c:29) Note: see also the FAQ in the source distribution. It contains workarounds to several common problems. In particular, if Valgrind aborted or crashed after identifying problems in your program, there's a good chance that fixing those problems will prevent Valgrind aborting or crashing, especially if it happened in m_mallocfree.c. If that doesn't help, please report this bug to: www.valgrind.org In the bug report, send all the above text, the valgrind version, and what OS and version you are using. Thanks. $ file helgrind/tests/tc12_rwl_trivial helgrind/tests/tc12_rwl_trivial: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=f5d2b09e348834b0a9c00c65487771d10f9bbc1f, not stripped $ gcc --version gcc (Ubuntu 6.3.0-12ubuntu2) 6.3.0 20170406 Copyright (C) 2016 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ ./vg-in-place --version -v valgrind-3.13.0.SVN-16373M-vex-3369
The problem is reproducible even with 'none' tool: $ ./vg-in-place --tool=none helgrind/tests/tc12_rwl_trivial ==29554== Nulgrind, the minimal Valgrind tool ==29554== Copyright (C) 2002-2017, and GNU GPL'd, by Nicholas Nethercote. ==29554== Using Valgrind-3.13.0.SVN and LibVEX; rerun with -h for copyright info ==29554== Command: helgrind/tests/tc12_rwl_trivial ==29554== vex: the `impossible' happened: disAMode(x86): not an addr! vex storage: T total 26363116 bytes allocated vex storage: P total 384 bytes allocated valgrind: the 'impossible' happened: LibVEX called failure_exit(). host stacktrace: ==29554== at 0x580A62CB: show_sched_status_wrk (m_libcassert.c:355) ==29554== by 0x580A63FD: report_and_quit (m_libcassert.c:426) ==29554== by 0x580A65AC: vgPlain_core_panic_at (m_libcassert.c:502) ==29554== by 0x580A65CA: vgPlain_core_panic (m_libcassert.c:512) ==29554== by 0x58019F6C: failure_exit (m_translate.c:740) ==29554== by 0x580E76B3: vpanic (main_util.c:231) ==29554== by 0x58109C2B: disAMode (guest_x86_toIR.c:1564) ==29554== by 0x58129ECC: disInstr_X86_WRK (guest_x86_toIR.c:15322) ==29554== by 0x5812B761: disInstr_X86 (guest_x86_toIR.c:15456) ==29554== by 0x580FE930: bb_to_IR (guest_generic_bb_to_IR.c:365) ==29554== by 0x580E4ACF: LibVEX_FrontEnd (main_main.c:558) ==29554== by 0x580E5302: LibVEX_Translate (main_main.c:1173) ==29554== by 0x5801C827: vgPlain_translate (m_translate.c:1791) ==29554== by 0x58053368: handle_chain_me (scheduler.c:1084) ==29554== by 0x58055067: vgPlain_scheduler (scheduler.c:1428) ==29554== by 0x58065DB7: run_a_thread_NORETURN (syswrap-linux.c:103) sched status: running_tid=1 Thread 1: status = VgTs_Runnable (lwpid 29554) ==29554== at 0x485F818: pthread_rwlock_unlock (pthread_rwlock_unlock.c:38) ==29554== by 0x10891F: safe_pthread_rwlock_unlock (safe-pthread.h:58) ==29554== by 0x108AF9: main (tc12_rwl_trivial.c:29)
(In reply to Ivo Raisr from comment #1) That's weird. I have never seen the x86 front end fail in that way before, nor for that matter the amd64 front end (it has basically identical logic.) disAMode should never be called with a modrm byte that indicates in fact a register. Do you have any local modifications? Or is there some inconsistent compilation problem? I can't imagine what through, given that disAMode and all its callers are in the same source file.
Whoa! Reproduced. Investigating.
Seems like the offending instruction is 'xend' from __pthread_rwlock_unlock().
VEX SVN commit r3370. Valgrind SVN commit 16375.