https://bugs.kde.org/show_bug.cgi?id=395246

            Bug ID: 395246
           Summary: vex amd64->IR: unhandled instruction bytes:
           Product: valgrind
           Version: 3.10.0
          Platform: FreeBSD Ports
                OS: FreeBSD
            Status: UNCONFIRMED
          Severity: major
          Priority: NOR
         Component: memcheck
          Assignee: jsew...@acm.org
          Reporter: joun...@yahoo.co.uk
  Target Milestone: ---

Similar to: https://bugs.kde.org/show_bug.cgi?id=373166

With any utility program: /bin/date /bin/echo ... the following error. The
system is 64-bit Intel. I have tested vagrind in 32-bit machine (Intel) and
valgrind does not work there either. The bug was not in my code. 

Version was (the 64-bit bug):

$ valgrind --version
valgrind-3.10.1


The systems were:

CURRENT:

$ uname -a # 64-bit (the error)
FreeBSD xxxxxxx 12.0-CURRENT FreeBSD 12.0-CURRENT #5 r333605: Wed May 16
13:10:26 EEST 2018
root@xxxxxxxx:/usr/obj/usr/src/amd64.amd64/sys/XXXXXX_64bit  amd64

RELEASE:

$ uname -a # 32-bit (the latter error)
FreeBSD xxxxxxx 11.1-RELEASE-p9 FreeBSD 11.1-RELEASE-p9 #0: Tue Apr  3 16:51:52
UTC 2018
r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  i386

The systems are under development and the port may have changes to the
original.

The error looks like the following:

_______________________________________

64-bit:

$ valgrind /bin/date
==9140== Memcheck, a memory error detector
==9140== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==9140== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==9140== Command: /bin/date
==9140== 
vex amd64->IR: unhandled instruction bytes: 0xC4 0xE2 0x4D 0x8E 0x10 0xC4 0xC1
0x45
vex amd64->IR:   REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0
vex amd64->IR:   VEX=1 VEX.L=1 VEX.nVVVV=0x6 ESC=0F38
vex amd64->IR:   PFX.66=1 PFX.F2=0 PFX.F3=0
==9140== valgrind: Unrecognised instruction at address 0x4d3c0ae.
==9140==    at 0x4D3C0AE: ??? (in /lib/libc.so.7)
==9140==    by 0x49249: ???
==9140==    by 0x4D93AB3: ??? (in /lib/libc.so.7)
==9140==    by 0x7FEFFF67F: ???
==9140==    by 0x4D90191: ??? (in /lib/libc.so.7)
==9140==    by 0x4D917FF: ??? (in /lib/libc.so.7)
==9140==    by 0x4E3D7FF: ??? (in /lib/libc.so.7)
==9140==    by 0x4828DEF: ???
==9140==    by 0x4E321B1: ??? (in /lib/libc.so.7)
==9140== Your program just tried to execute an instruction that Valgrind
==9140== did not recognise.  There are two possible reasons for this.
==9140== 1. Your program has a bug and erroneously jumped to a non-code
==9140==    location.  If you are running Memcheck and you just saw a
==9140==    warning about a bad jump, it's probably your program's fault.
==9140== 2. The instruction is legitimate but Valgrind doesn't handle it,
==9140==    i.e. it's Valgrind's fault.  If you think this is the case or
==9140==    you are not sure, please let us know and we'll try to fix it.
==9140== Either way, Valgrind will now raise a SIGILL signal which will
==9140== probably kill your program.
==9140== 
==9140== Process terminating with default action of signal 4 (SIGILL): dumping
core
==9140==  Illegal opcode at address 0x4D3C0AE
==9140==    at 0x4D3C0AE: ??? (in /lib/libc.so.7)
==9140==    by 0x49249: ???
==9140==    by 0x4D93AB3: ??? (in /lib/libc.so.7)
==9140==    by 0x7FEFFF67F: ???
==9140==    by 0x4D90191: ??? (in /lib/libc.so.7)
==9140==    by 0x4D917FF: ??? (in /lib/libc.so.7)
==9140==    by 0x4E3D7FF: ??? (in /lib/libc.so.7)
==9140==    by 0x4828DEF: ???
==9140==    by 0x4E321B1: ??? (in /lib/libc.so.7)
==9140== 
==9140== HEAP SUMMARY:
==9140==     in use at exit: 0 bytes in 0 blocks
==9140==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==9140== 
==9140== All heap blocks were freed -- no leaks are possible
==9140== 
==9140== For counts of detected and suppressed errors, rerun with: -v
==9140== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Illegal instruction

_______________________________________

32-bit:

$ valgrind /bin/echo "1"
valgrind: I failed to allocate space for the application's stack.
valgrind: This may be the result of a very large --main-stacksize=
valgrind: setting.  Cannot continue.  Sorry.

$ valgrind /bin/date
valgrind: I failed to allocate space for the application's stack.
valgrind: This may be the result of a very large --main-stacksize=
valgrind: setting.  Cannot continue.  Sorry.

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to