[valgrind] [Bug 395246] vex amd64->IR: unhandled instruction bytes:

2018-06-13 Thread Jouni Laakso
https://bugs.kde.org/show_bug.cgi?id=395246

Jouni Laakso  changed:

   What|Removed |Added

 Resolution|--- |UNMAINTAINED
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from Jouni Laakso  ---
32-bit error added to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228973
.  Unfortunately the version in 12-CURRENT is old. Even older version can be
found from an URL: https://bitbucket.org/stass/valgrind-freebsd/overview .
Where the ports version is I don't know. Compiling valgrind from source:

# ./autogen.sh 
running: aclocal
running: autoheader
running: automake -a
running: autoconf
# sh ./configure --prefix=/usr/local/valgrind
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... ./install-sh -c -d
...
checking for gcc... no
checking for cc... cc
checking whether the C compiler works... yes
...
checking for a supported version of gcc... ok (clang-6.0.0)
checking build system type... x86_64-unknown-freebsd12.0
checking host system type... x86_64-unknown-freebsd12.0
checking for a supported CPU... ok (x86_64)
checking for a 64-bit only build... no
checking for a 32-bit only build... no
checking for a supported OS... no (freebsd12.0)
configure: error: Valgrind is operating system specific. Sorry.

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

[valgrind] [Bug 395246] New: vex amd64->IR: unhandled instruction bytes:

2018-06-11 Thread Jouni Laakso
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 xxx 12.0-CURRENT FreeBSD 12.0-CURRENT #5 r333605: Wed May 16
13:10:26 EEST 2018
root@:/usr/obj/usr/src/amd64.amd64/sys/XX_64bit  amd64

RELEASE:

$ uname -a # 32-bit (the latter error)
FreeBSD xxx 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.n=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.