Red Hat Bugzilla – Bug 515768
valgrind doesn't recognize multiple operand size prefixes
Last modified: 2018-10-27 11:54:08 EDT
Created attachment 356383 [details] reproducer program Description of problem: If an x86_64 program contains 5 or more 0x66 (operand size) prefixes, e.g. 40044c: 66 66 66 66 66 66 2e nopw %cs:0x0(%rax,%rax,1) valgrind complains with vex amd64->IR: unhandled instruction bytes: 0x66 0x66 0x66 0x66 This has been reported and fixed upstream at http://bugs.kde.org/show_bug.cgi?id=148447 Version-Release number of selected component (if applicable): valgrind-3.2.1-6.el5 How reproducible: every time Steps to Reproduce: 1. gcc -g -o nopw nopw.c (see attached) 2. valgrind ./nopw Actual results: valgrind gives an error "unhandled instruction bytes" Expected results: no errors Additional info:
Created attachment 356385 [details] patch from upstream
Just to clarify comment 0 since I didn't copy-and-paste all the lines, the full instruction is: 40044c: 66 66 66 66 66 66 2e nopw %cs:0x0(%rax,%rax,1) 400453: 0f 1f 84 00 00 00 00 40045a: 00
The "Illegal Instruction" bug still exists with patched 3.2.1-7 version. Here is the output: valgrind ./ibyhogtw.linux_64.tsk -pldir libpurple_install / -t -m 3882 -l ./ibyhogtw.log ==12646== Memcheck, a memory error detector. ==12646== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al. ==12646== Using LibVEX rev 1658, a library for dynamic binary translation. ==12646== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP. ==12646== Using valgrind-3.2.1, a dynamic binary instrumentation framework. ==12646== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al. ==12646== For more details, rerun with: -v ==12646== (process:12646): GLib-CRITICAL **: g_main_loop_is_running: assertion `loop != NULL' failed PLUGINS: /bb/mbig/mbig2617/libpurple_install/ vex amd64->IR: unhandled instruction bytes: 0xF0 0xF 0xB0 0x4D ==12646== valgrind: Unrecognised instruction at address 0x487398. ==12646== Your program just tried to execute an instruction that Valgrind ==12646== did not recognise. There are two possible reasons for this. ==12646== 1. Your program has a bug and erroneously jumped to a non-code ==12646== location. If you are running Memcheck and you just saw a ==12646== warning about a bad jump, it's probably your program's fault. ==12646== 2. The instruction is legitimate but Valgrind doesn't handle it, ==12646== i.e. it's Valgrind's fault. If you think this is the case or ==12646== you are not sure, please let us know and we'll try to fix it. ==12646== Either way, Valgrind will now raise a SIGILL signal which will ==12646== probably kill your program. ==12646== ==12646== Process terminating with default action of signal 4 (SIGILL): dumping core ==12646== Illegal opcode at address 0x487398 ==12646== at 0x487398: BLP::bcemt_RecursiveMutexImpl<BLP::bces_Platform::PosixThreads>::lock() (in /n et/nnap4211-s/vol/mbig6/mbig2617/openib/ibyhogtw/ibyhogtw.linux_64.tsk) ==12646== by 0x483379: BLP::bael_FixedSizeRecordBuffer::removeAll() (in /net/nnap4211-s/vol/mbig6/mbig2617/op enib/ibyhogtw/ibyhogtw.linux_64.tsk) ==12646== by 0x4717F2: BLP::bael_Logger::~bael_Logger() (in /net/nnap4211-s/vol/mbig6/mbig2617/openib/ibyhogt w/ibyhogtw.linux_64.tsk) ==12646== by 0x471A85: BLP::bael_LoggerManager::~bael_LoggerManager() (in /net/nnap4211-s/vol/mbig6/mbig2617/ openib/ibyhogtw/ibyhogtw.linux_64.tsk) ==12646== by 0x406943: ibyhogtw::LoggerManager::~LoggerManager() (bslma_deleterhelper.h:120) ==12646== by 0x434FD3: main (ibyhogtw.m.cpp:254) ==12646== ==12646== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 32 from 1) ==12646== malloc/free: in use at exit: 305,933 bytes in 3,582 blocks. ==12646== malloc/free: 9,624 allocs, 6,042 frees, 2,450,975 bytes allocated. ==12646== For counts of detected errors, rerun with: -v ==12646== searching for pointers to 3,582 not-freed blocks. ==12646== checked 719,752 bytes. ==12646== ==12646== LEAK SUMMARY: ==12646== definitely lost: 84,331 bytes in 836 blocks. ==12646== possibly lost: 6,808 bytes in 65 blocks. ==12646== still reachable: 214,794 bytes in 2,681 blocks. ==12646== suppressed: 0 bytes in 0 blocks. ==12646== Use --leak-check=full to see details of leaked memory. Illegal instruction PLEASE NOTE: The same binary runs fine under valgrind 3.4.1.
The RHEL5.5 beta version of valgrind fixes the issue reported earlier. linxdev8 # rpm -q valgrind valgrind-3.5.0-1.el5.x86_64 linxdev8 # valgrind --tool=memcheck bces_atomicutilimpl_amd64.t.dbg_exc_mt_64 1 ==23179== Memcheck, a memory error detector ==23179== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==23179== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==23179== Command: bces_atomicutilimpl_amd64.t.dbg_exc_mt_64 1 ==23179== TEST bces_atomicutilimpl_amd64.t.cpp CASE 1 ==23179== ==23179== HEAP SUMMARY: ==23179== in use at exit: 4,290 bytes in 181 blocks ==23179== total heap usage: 486 allocs, 305 frees, 5,411 bytes allocated ==23179== ==23179== LEAK SUMMARY: ==23179== definitely lost: 0 bytes in 0 blocks ==23179== indirectly lost: 0 bytes in 0 blocks ==23179== possibly lost: 0 bytes in 0 blocks ==23179== still reachable: 4,290 bytes in 181 blocks ==23179== suppressed: 0 bytes in 0 blocks ==23179== Rerun with --leak-check=full to see details of leaked memory ==23179== ==23179== For counts of detected and suppressed errors, rerun with: -v ==23179== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2010-0272.html