Bug 344547

Summary:	vex x86->IR: unhandled instruction bytes: 0xC5 0xF8 0x77 0xE9
Product:	[Developer tools] valgrind	Reporter:	Nikos Chantziaras <realnc>
Component:	vex	Assignee:	Julian Seward <jseward>
Status:	VERIFIED LATER
Severity:	normal	CC:	ivosh
Priority:	NOR
Version First Reported In:	3.10 SVN
Target Milestone:	---
Platform:	Compiled Sources
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description Nikos Chantziaras 2015-02-25 06:06:09 UTC

When running 32-bit binaries in Valgrind, it aborts with:

  vex x86->IR: unhandled instruction bytes: 0xC5 0xF8 0x77 0xE9

This is a 64-bit system with 32-bit multilib support (/usr/lib32).

I had this problem with 3.10.1 as provided by Gentoo, but I also reproduced it when building from the current SVN trunk.

The system's 32-bit glibc (2.20) is built with "-march=native". I rebuilt it with "-march=i686" but it did not help. I don't know if there's any hand-crafted asm code and/or cpu detection going on in glibc :-/

The problem appears regardless of which 32-bit binary is run, as long as it makes use of C string functions.


$ uname -a
Linux gentoo 3.14.33-gentoo #1 SMP PREEMPT Thu Feb 12 15:49:37 EET 2015 x86_64 Intel(R) Core(TM) i5-2500K CPU @ 3.30GHz GenuineIntel GNU/Linux


$ ~/opt/valgrind/bin/valgrind -v ./hugor.linux32
==18669== Memcheck, a memory error detector
==18669== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==18669== Using Valgrind-3.11.0.SVN and LibVEX; rerun with -h for copyright info
==18669== Command: ./hugor.linux32
==18669== 
--18669-- Valgrind options:
--18669--    -v
--18669-- Contents of /proc/version:
--18669--   Linux version 3.14.33-gentoo (realnc@gentoo) (gcc version 4.9.2 (Gentoo 4.9.2 p1.0, pie-0.6.2) ) #1 SMP PREEMPT Thu Feb 12 15:49:37 EET 2015
--18669-- 
--18669-- Arch and hwcaps: X86, LittleEndian, x86-mmxext-sse1-sse2-sse3
--18669-- Page sizes: currently 4096, max supported 4096
--18669-- Valgrind library directory: /home/realnc/opt/valgrind/lib/valgrind
--18669-- Reading syms from /lib32/ld-2.20.so
--18669--   Considering /usr/lib/debug/lib32/ld-2.20.so.debug ..
--18669--   .. CRC is valid
--18669-- Reading syms from /home/realnc/tmp/icj/Hugor-icj/hugor.linux32
--18669--    object doesn't have a symbol table
--18669-- Reading syms from /home/realnc/opt/valgrind/lib/valgrind/memcheck-x86-linux
--18669--    object doesn't have a dynamic symbol table
--18669-- Scheduler: using generic scheduler lock implementation.
--18669-- Reading suppressions file: /home/realnc/opt/valgrind/lib/valgrind/default.supp
==18669== embedded gdbserver: reading from /tmp/vgdb-pipe-from-vgdb-to-18669-by-realnc-on-???
==18669== embedded gdbserver: writing to   /tmp/vgdb-pipe-to-vgdb-from-18669-by-realnc-on-???
==18669== embedded gdbserver: shared mem   /tmp/vgdb-pipe-shared-mem-vgdb-18669-by-realnc-on-???
==18669== 
==18669== TO CONTROL THIS PROCESS USING vgdb (which you probably
==18669== don't want to do, unless you know exactly what you're doing,
==18669== or are doing some strange experiment):
==18669==   /home/realnc/opt/valgrind/lib/valgrind/../../bin/vgdb --pid=18669 ...command...
==18669== 
==18669== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==18669==   /path/to/gdb ./hugor.linux32
==18669== and then give GDB the following command
==18669==   target remote | /home/realnc/opt/valgrind/lib/valgrind/../../bin/vgdb --pid=18669
==18669== --pid is optional if only one valgrind process is running
==18669== 
--18669-- REDIR: 0x4017e40 (ld-linux.so.2:strlen) redirected to 0x38067f72 (vgPlain_x86_linux_REDIR_FOR_strlen)
--18669-- REDIR: 0x4017c50 (ld-linux.so.2:index) redirected to 0x38067f4d (vgPlain_x86_linux_REDIR_FOR_index)
--18669-- Reading syms from /home/realnc/opt/valgrind/lib/valgrind/vgpreload_core-x86-linux.so
--18669-- Reading syms from /home/realnc/opt/valgrind/lib/valgrind/vgpreload_memcheck-x86-linux.so
==18669== WARNING: new redirection conflicts with existing -- ignoring it
--18669--     old: 0x04017e40 (strlen              ) R-> (0000.0) 0x38067f72 vgPlain_x86_linux_REDIR_FOR_strlen
--18669--     new: 0x04017e40 (strlen              ) R-> (2007.0) 0x0402ce40 strlen
--18669-- Reading syms from /usr/lib32/libSDL-1.2.so.0.11.4
--18669--   Considering /usr/lib/debug/usr/lib32/libSDL-1.2.so.0.11.4.debug ..
--18669--   .. CRC is valid
--18669-- Reading syms from /usr/lib32/libvorbisfile.so.3.3.6
--18669--    object doesn't have a symbol table
--18669-- Reading syms from /usr/lib32/qt4/libQtGui.so.4.8.6
--18669--    object doesn't have a symbol table
--18669-- Reading syms from /usr/lib32/qt4/libQtCore.so.4.8.6
--18669--    object doesn't have a symbol table
--18669-- Reading syms from /lib32/libpthread-2.20.so
--18669--   Considering /usr/lib/debug/lib32/libpthread-2.20.so.debug ..
--18669--   .. CRC is valid
--18669-- Reading syms from /usr/lib64/gcc/x86_64-pc-linux-gnu/4.9.2/32/libstdc++.so.6.0.20
--18669--    object doesn't have a symbol table
--18669-- Reading syms from /lib32/libm-2.20.so
--18669--   Considering /usr/lib/debug/lib32/libm-2.20.so.debug ..
--18669--   .. CRC is valid
--18669-- Reading syms from /usr/lib64/gcc/x86_64-pc-linux-gnu/4.9.2/32/libgcc_s.so.1
--18669--    object doesn't have a symbol table
--18669-- Reading syms from /lib32/libc-2.20.so
--18669--   Considering /usr/lib/debug/lib32/libc-2.20.so.debug ..
--18669--   .. CRC is valid
--18669-- Reading syms from /usr/lib32/libglib-2.0.so.0.4200.1
--18669--    object doesn't have a symbol table
--18669-- Reading syms from /usr/lib32/libgthread-2.0.so.0.4200.1
--18669--    object doesn't have a symbol table
--18669-- Reading syms from /lib32/libdl-2.20.so
--18669--   Considering /usr/lib/debug/lib32/libdl-2.20.so.debug ..
--18669--   .. CRC is valid
--18669-- Reading syms from /usr/lib32/libpulse-simple.so.0.1.0
--18669--    object doesn't have a symbol table
--18669-- Reading syms from /usr/lib32/libpulse.so.0.18.0
--18669--    object doesn't have a symbol table
--18669-- Reading syms from /usr/lib32/libvorbis.so.0.4.7
--18669--    object doesn't have a symbol table
--18669-- Reading syms from /usr/lib32/libogg.so.0.8.2
--18669--    object doesn't have a symbol table
--18669-- Reading syms from /usr/lib32/libpng16.so.16.16.0
--18669--    object doesn't have a symbol table
--18669-- Reading syms from /lib32/libz.so.1.2.8
--18669--    object doesn't have a symbol table
--18669-- Reading syms from /usr/lib32/libfreetype.so.6.11.4
--18669--    object doesn't have a symbol table
--18669-- Reading syms from /usr/lib32/libSM.so.6.0.1
--18669--    object doesn't have a symbol table
--18669-- Reading syms from /usr/lib32/libICE.so.6.3.0
--18669--    object doesn't have a symbol table
--18669-- Reading syms from /usr/lib32/libXi.so.6.1.0
--18669--    object doesn't have a symbol table
--18669-- Reading syms from /usr/lib32/libXrender.so.1.3.0
--18669--    object doesn't have a symbol table
--18669-- Reading syms from /usr/lib32/libXrandr.so.2.2.0
--18669--    object doesn't have a symbol table
--18669-- Reading syms from /usr/lib32/libXfixes.so.3.1.0
--18669--    object doesn't have a symbol table
--18669-- Reading syms from /usr/lib32/libXcursor.so.1.0.2
--18669--    object doesn't have a symbol table
--18669-- Reading syms from /usr/lib32/libfontconfig.so.1.8.0
--18669--    object doesn't have a symbol table
--18669-- Reading syms from /usr/lib32/libXext.so.6.4.0
--18669--    object doesn't have a symbol table
--18669-- Reading syms from /usr/lib32/libX11.so.6.3.0
--18669--    object doesn't have a symbol table
--18669-- Reading syms from /lib32/librt-2.20.so
--18669--   Considering /usr/lib/debug/lib32/librt-2.20.so.debug ..
--18669--   .. CRC is valid
--18669-- Reading syms from /usr/lib32/pulseaudio/libpulsecommon-6.0.so
--18669--    object doesn't have a symbol table
--18669-- Reading syms from /usr/lib32/libX11-xcb.so.1.0.0
--18669--    object doesn't have a symbol table
--18669-- Reading syms from /usr/lib32/libxcb.so.1.1.0
--18669--    object doesn't have a symbol table
--18669-- Reading syms from /usr/lib32/libXtst.so.6.1.0
--18669--    object doesn't have a symbol table
--18669-- Reading syms from /usr/lib32/libjson-c.so.2.0.1
--18669--    object doesn't have a symbol table
--18669-- Reading syms from /usr/lib32/libwrap.so.0.7.6
--18669--    object doesn't have a symbol table
--18669-- Reading syms from /usr/lib32/libsndfile.so.1.0.25
--18669--    object doesn't have a symbol table
--18669-- Reading syms from /usr/lib32/libasyncns.so.0.3.1
--18669--    object doesn't have a symbol table
--18669-- Reading syms from /usr/lib32/libdbus-1.so.3.8.11
--18669--    object doesn't have a symbol table
--18669-- Reading syms from /usr/lib32/libcap.so.2.22
--18669--    object doesn't have a symbol table
--18669-- Reading syms from /usr/lib32/libbz2.so.1.0.6
--18669--    object doesn't have a symbol table
--18669-- Reading syms from /usr/lib32/libuuid.so.1.3.0
--18669--    object doesn't have a symbol table
--18669-- Reading syms from /usr/lib32/libexpat.so.1.6.0
--18669--    object doesn't have a symbol table
--18669-- Reading syms from /usr/lib32/libXau.so.6.0.0
--18669--    object doesn't have a symbol table
--18669-- Reading syms from /usr/lib32/libXdmcp.so.6.0.0
--18669--    object doesn't have a symbol table
--18669-- Reading syms from /usr/lib32/libFLAC.so.8.3.0
--18669--    object doesn't have a symbol table
--18669-- Reading syms from /usr/lib32/libvorbisenc.so.2.0.10
--18669--    object doesn't have a symbol table
--18669-- Reading syms from /lib32/libresolv-2.20.so
--18669--   Considering /usr/lib/debug/lib32/libresolv-2.20.so.debug ..
--18669--   .. CRC is valid
--18669-- Reading syms from /usr/lib32/libattr.so.1.1.0
--18669--    object doesn't have a symbol table
--18669-- REDIR: 0x5061250 (libc.so.6:strnlen) redirected to 0x4024552 (_vgnU_ifunc_wrapper)
--18669-- REDIR: 0x50631b0 (libc.so.6:strncasecmp) redirected to 0x4024552 (_vgnU_ifunc_wrapper)
--18669-- REDIR: 0x506a550 (libc.so.6:memrchr) redirected to 0x4024552 (_vgnU_ifunc_wrapper)
--18669-- REDIR: 0x507d0f0 (libc.so.6:wcslen) redirected to 0x4024552 (_vgnU_ifunc_wrapper)
--18669-- REDIR: 0x5060a70 (libc.so.6:strcmp) redirected to 0x4024552 (_vgnU_ifunc_wrapper)
--18669-- REDIR: 0x50612f0 (libc.so.6:strncmp) redirected to 0x4024552 (_vgnU_ifunc_wrapper)
--18669-- REDIR: 0x5061fc0 (libc.so.6:strstr) redirected to 0x4031100 (strstr)
--18669-- REDIR: 0x5061400 (libc.so.6:__GI_strrchr) redirected to 0x402c800 (__GI_strrchr)
--18669-- REDIR: 0x5061190 (libc.so.6:__GI_strlen) redirected to 0x402cdc0 (__GI_strlen)
--18669-- REDIR: 0x4ed7290 (libstdc++.so.6:operator new(unsigned int)) redirected to 0x402a5ab (operator new(unsigned int))
--18669-- REDIR: 0x505cd40 (libc.so.6:malloc) redirected to 0x402a105 (malloc)
--18669-- REDIR: 0x5063320 (libc.so.6:memcpy) redirected to 0x4024552 (_vgnU_ifunc_wrapper)
--18669-- REDIR: 0x510c0c0 (libc.so.6:__memcpy_ssse3) redirected to 0x402e780 (memcpy)
--18669-- REDIR: 0x5062c80 (libc.so.6:memset) redirected to 0x4024552 (_vgnU_ifunc_wrapper)
--18669-- REDIR: 0x510afb0 (libc.so.6:__memset_sse2) redirected to 0x4030370 (memset)
--18669-- REDIR: 0x5061140 (libc.so.6:strlen) redirected to 0x4024552 (_vgnU_ifunc_wrapper)
--18669-- REDIR: 0x506a890 (libc.so.6:__strlen_sse2_bsf) redirected to 0x402cda0 (strlen)
--18669-- REDIR: 0x5119b10 (libc.so.6:__strncmp_ssse3) redirected to 0x402d580 (strncmp)
--18669-- REDIR: 0x51186a0 (libc.so.6:__strcmp_ssse3) redirected to 0x402df20 (strcmp)
--18669-- REDIR: 0x505d350 (libc.so.6:free) redirected to 0x402b0dd (free)
--18669-- REDIR: 0x505d400 (libc.so.6:realloc) redirected to 0x402bde7 (realloc)
--18669-- REDIR: 0x505d6b0 (libc.so.6:calloc) redirected to 0x402bc59 (calloc)
--18669-- REDIR: 0x5063380 (libc.so.6:__GI_memcpy) redirected to 0x402ea80 (__GI_memcpy)
--18669-- REDIR: 0x5060ad0 (libc.so.6:__GI_strcmp) redirected to 0x402df70 (__GI_strcmp)
--18669-- REDIR: 0x506a790 (libc.so.6:__GI_strncmp) redirected to 0x402d610 (__GI_strncmp)
--18669-- REDIR: 0x5065100 (libc.so.6:strchrnul) redirected to 0x4030a10 (strchrnul)
vex x86->IR: unhandled instruction bytes: 0xC5 0xF8 0x77 0xE9
==18669== valgrind: Unrecognised instruction at address 0x502a9d6.
==18669==    at 0x502A9D6: vfprintf (vfprintf.c:1642)
==18669==    by 0x50E00EB: __vsnprintf_chk (vsnprintf_chk.c:63)
==18669==    by 0x568DFB5: pa_sprintf_malloc (in /usr/lib32/pulseaudio/libpulsecommon-6.0.so)
==18669==    by 0x5692F84: pa_open_config_file (in /usr/lib32/pulseaudio/libpulsecommon-6.0.so)
==18669==    by 0x567D549: pa_client_conf_load (in /usr/lib32/pulseaudio/libpulsecommon-6.0.so)
==18669==    by 0x530471E: pa_context_new_with_proplist (in /usr/lib32/libpulse.so.0.18.0)
==18669==    by 0x530482D: pa_context_new (in /usr/lib32/libpulse.so.0.18.0)
==18669==    by 0x52F3735: pa_simple_new (in /usr/lib32/libpulse-simple.so.0.1.0)
==18669==    by 0x40A49F3: Audio_Available (SDL_pulseaudio.c:235)
==18669==    by 0x407753E: SDL_AudioInit (SDL_audio.c:360)
==18669==    by 0x4076205: SDL_InitSubSystem (SDL.c:105)
==18669==    by 0x4076261: SDL_Init (SDL.c:162)
==18669== Your program just tried to execute an instruction that Valgrind
==18669== did not recognise.  There are two possible reasons for this.
==18669== 1. Your program has a bug and erroneously jumped to a non-code
==18669==    location.  If you are running Memcheck and you just saw a
==18669==    warning about a bad jump, it's probably your program's fault.
==18669== 2. The instruction is legitimate but Valgrind doesn't handle it,
==18669==    i.e. it's Valgrind's fault.  If you think this is the case or
==18669==    you are not sure, please let us know and we'll try to fix it.
==18669== Either way, Valgrind will now raise a SIGILL signal which will
==18669== probably kill your program.
==18669== 
==18669== Process terminating with default action of signal 4 (SIGILL)
==18669==  Illegal opcode at address 0x502A9D6
==18669==    at 0x502A9D6: vfprintf (vfprintf.c:1642)
==18669==    by 0x50E00EB: __vsnprintf_chk (vsnprintf_chk.c:63)
==18669==    by 0x568DFB5: pa_sprintf_malloc (in /usr/lib32/pulseaudio/libpulsecommon-6.0.so)
==18669==    by 0x5692F84: pa_open_config_file (in /usr/lib32/pulseaudio/libpulsecommon-6.0.so)
==18669==    by 0x567D549: pa_client_conf_load (in /usr/lib32/pulseaudio/libpulsecommon-6.0.so)
==18669==    by 0x530471E: pa_context_new_with_proplist (in /usr/lib32/libpulse.so.0.18.0)
==18669==    by 0x530482D: pa_context_new (in /usr/lib32/libpulse.so.0.18.0)
==18669==    by 0x52F3735: pa_simple_new (in /usr/lib32/libpulse-simple.so.0.1.0)
==18669==    by 0x40A49F3: Audio_Available (SDL_pulseaudio.c:235)
==18669==    by 0x407753E: SDL_AudioInit (SDL_audio.c:360)
==18669==    by 0x4076205: SDL_InitSubSystem (SDL.c:105)
==18669==    by 0x4076261: SDL_Init (SDL.c:162)
==18669== 
==18669== HEAP SUMMARY:
==18669==     in use at exit: 7,140 bytes in 46 blocks
==18669==   total heap usage: 53 allocs, 7 frees, 7,340 bytes allocated
==18669== 
==18669== Searching for pointers to 46 not-freed blocks
==18669== Checked 1,651,520 bytes
==18669== 
==18669== LEAK SUMMARY:
==18669==    definitely lost: 0 bytes in 0 blocks
==18669==    indirectly lost: 0 bytes in 0 blocks
==18669==      possibly lost: 0 bytes in 0 blocks
==18669==    still reachable: 7,140 bytes in 46 blocks
==18669==         suppressed: 0 bytes in 0 blocks
==18669== Rerun with --leak-check=full to see details of leaked memory
==18669== 
==18669== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==18669== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Illegal instruction

Comment 1 Julian Seward 2015-03-05 15:27:41 UTC

x86 (32-bit) only supports up to and including SSSE3.  This instruction
is probably AVX, a much more recent extension than SSSE3.  Can you
try with x86_64 instead?  That supports everything up to and including AVX2.

Comment 2 Nikos Chantziaras 2015-03-05 16:08:03 UTC

x86_64 can't run 32-bit binaries.

The use case here is that the 32-bit version of an application has some bugs that the 64-bit version does not. So debugging the 64-bit version would not help anything.

However, if supporting these instructions in the 32-bit version of Valgrind is out of the question, then feel free to close this bug.

Comment 3 Ivo Raisr 2017-07-23 05:11:48 UTC

Supporting SSE4 or AVX instructions in 32-bit x86 programs is *not* out of the question. There needs to be just someone who will implement the required functionality. It could be you!

Comment 4 Nikos Chantziaras 2017-07-23 05:57:03 UTC

It seems rather unlikely at this point, which is why I closed it.

I'm changing it to "Verified/Later" since you think it's not completely out of the question.

I don't think it would be me adding the feature though. I'm afraid my hands-on experience with machine instructions only went as far as setting VGA mode 13h in DOS back in 1993 ;-)