RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 866941 - Regression vex amd64->IR: unhandled instruction bytes: 0xF0 0xF 0xC0 0x10 0x84 0xD2 0xF 0x95 (lock xaddb)
Summary: Regression vex amd64->IR: unhandled instruction bytes: 0xF0 0xF 0xC0 0x10 0x8...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: valgrind
Version: 6.4
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Mark Wielaard
QA Contact: qe-baseos-tools-bugs
URL:
Whiteboard:
Depends On: 866793
Blocks: 866943
TreeView+ depends on / blocked
 
Reported: 2012-10-16 11:22 UTC by Mark Wielaard
Modified: 2013-02-21 08:52 UTC (History)
4 users (show)

Fixed In Version: valgrind-3.8.1-3.2.el6
Doc Type: Bug Fix
Doc Text:
Probably no documentation necessary. This was a regression in valgrind 3.8.0 which was never released before in RHEL6. The previous version in RHEL6 was based on 3.6.0. x86_64 programs using some variants of the xaddb instruction would not run under valgrind. This was a regression introduced in valgrind 3.8.0. Such programs would run normally under valgrind before. With this fix they again run under valgrind without errors.
Clone Of: 866793
: 866943 (view as bug list)
Environment:
Last Closed: 2013-02-21 08:52:08 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
KDE Software Compilation 307106 0 None None None 2012-10-16 11:22:23 UTC
Red Hat Product Errata RHBA-2013:0347 0 normal SHIPPED_LIVE valgrind bug fix and enhancement update 2013-02-20 20:53:42 UTC

Description Mark Wielaard 2012-10-16 11:22:23 UTC 
+++ This bug was initially created as a clone of Bug #866793 +++

Originally https://bugzilla.redhat.com/show_bug.cgi?id=755242#c7

valgrind-3.8.1-3.fc17 fails.

[mrsam@octopus base]$ valgrind --tool=memcheck ./testhttpclientauth 
==28524== Memcheck, a memory error detector
==28524== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==28524== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==28524== Command: ./testhttpclientauth
==28524== 
vex amd64->IR: unhandled instruction bytes: 0xF0 0xF 0xC0 0x10 0x84 0xD2 0xF 0x95
vex amd64->IR:   REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0
vex amd64->IR:   VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=0F
vex amd64->IR:   PFX.66=0 PFX.F2=0 PFX.F3=0
==28524== valgrind: Unrecognised instruction at address 0x56c947.

--- Additional comment from jakub on 2012-10-16 03:35:51 EDT ---

Weird, that is lock xaddb %dl,(%rax), that ought to be handled...

--- Additional comment from mjw on 2012-10-16 03:51:37 EDT ---

confirmed, valgrind 3.7.0 works fine, but with 3.8.x and also with upstream valgrind SVN:

$ /usr/local/install/valgrind/bin/valgrind -q --vgdb-error=0 ./test
==4405== (action at startup) vgdb me ... 
==4405== 
==4405== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==4405==   /path/to/gdb ./test
==4405== and then give GDB the following command
==4405==   target remote | /usr/local/install/valgrind/lib/valgrind/../../bin/vgdb --pid=4405
==4405== --pid is optional if only one valgrind process is running
==4405== 

(gdb) target remote | /usr/local/install/valgrind/lib/valgrind/../../bin/vgdb --pid=4405
Remote debugging using | /usr/local/install/valgrind/lib/valgrind/../../bin/vgdb --pid=4405
relaying data between gdb and process 4405
Reading symbols from /lib64/ld-linux-x86-64.so.2...Reading symbols from /usr/lib/debug/lib64/ld-2.15.so.debug...done.
done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
[Switching to Thread 4405]
0x0000000004001530 in _start () from /lib64/ld-linux-x86-64.so.2
(gdb) c
Continuing.

Program received signal SIGILL, Illegal instruction.
0x00000000004004a7 in main ()
(gdb) disassemble 
Dump of assembler code for function main:
   0x000000000040049c <+0>:	push   %rbp
   0x000000000040049d <+1>:	mov    %rsp,%rbp
   0x00000000004004a0 <+4>:	mov    %edi,-0x4(%rbp)
   0x00000000004004a3 <+7>:	mov    %rsi,-0x10(%rbp)
=> 0x00000000004004a7 <+11>:	lock xadd %dl,(%rax)
   0x00000000004004ab <+15>:	mov    $0x0,%eax
   0x00000000004004b0 <+20>:	pop    %rbp
   0x00000000004004b1 <+21>:	retq   
End of assembler dump.
(gdb)

--- Additional comment from jakub on 2012-10-16 05:09:34 EDT ---

Created attachment 628051 [details]
valgrind-xaddb.patch

I'm probably missing something obvious, but to me it looks like xaddb handling in valgrind 3.7.x and earlier was misplaced and with AVX merge it got commented out.

--- Additional comment from mjw on 2012-10-16 05:39:15 EDT ---

Confirmed with upstream. "it got disabled during the massive reorganisation of that insn decoder last year, and never got re-enabled"

https://bugs.kde.org/show_bug.cgi?id=307106
Comment 2 Mark Wielaard 2012-10-16 12:15:46 UTC 
This is a x86_64 issue only. The simplest (bogus) binary to show this issue is:

int
main (int argc, char **argv)
{
  asm("xaddb %dl,(%rax)");
  return 0;
}

$ gcc -g -o test test.c

$ valgrind --tool=none ./test
[...]
==9187== Command: /tmp/test
==9187== 
vex amd64->IR: unhandled instruction bytes: 0xF 0xC0 0x10 0xB8 0x0 0x0 0x0 0x0
vex amd64->IR:   REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0
vex amd64->IR:   VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=0F
vex amd64->IR:   PFX.66=0 PFX.F2=0 PFX.F3=0
==9187== valgrind: Unrecognised instruction at address 0x4004a7.
Comment 3 Mark Wielaard 2012-10-16 12:32:12 UTC 
From the clone of this bug https://bugzilla.redhat.com/show_bug.cgi?id=866943

--- Comment #5 from Jakub Jelinek <jakub> ---
And even better:

int
main ()
{
  char a = 8;
  char b = 9;
  asm volatile ("lock xaddb %%dl, (%%rax)" : "=m" (b), "+d" (a) : "a" (&b) :
"memory");
  return 0;
}

because xaddb returns in %%dl the value read from memory before the atomic
modification.
Comment 6 errata-xmlrpc 2013-02-21 08:52:08 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-0347.html
Note You need to log in before you can comment on or make changes to this bug.