Bug 352549

Summary:	Valgrind (whether with memchek or callgrind) crashes with "unhandled instruction bytes"
Product:	[Developer tools] valgrind	Reporter:	Achkan <ashsalehi4133>
Component:	memcheck	Assignee:	Julian Seward <jseward>
Status:	RESOLVED NOT A BUG
Severity:	crash	CC:	flo2030, shlomif, tom
Priority:	NOR
Version First Reported In:	3.10 SVN
Target Milestone:	---
Platform:	Ubuntu
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:
Attachments:	attachment-10926-0.html

Description Achkan 2015-09-11 09:48:03 UTC

Valgrind (whether with memchek or callgrind) crashes with "unhandled instruction bytes"

vex amd64->IR: unhandled instruction bytes: 0xFF 0xFF 0xC5 0x79 0x6E 0xEA 0xC4 0x42
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=NONE
vex amd64->IR:   PFX.66=0 PFX.F2=0 PFX.F3=0

Reproducible: Always

Steps to Reproduce:
instructions of the style 

__m128i xminSIMD = _mm_set1_epi16 (xmin);

trigger the problem. 

Actual Results:  
vex amd64->IR: unhandled instruction bytes: 0xFF 0xFF 0xC5 0x79 0x6E 0xEA 0xC4 0x42
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=NONE
vex amd64->IR:   PFX.66=0 PFX.F2=0 PFX.F3=0

Comment 1 Shlomi Fish 2015-09-11 10:29:18 UTC

Hi!

Can you provide the C or C++ sources for a self-contained, reproducing example (with build instructions)?

Comment 2 Achkan 2015-09-11 11:25:47 UTC

Created attachment 94508 [details]
attachment-10926-0.html

Thank you for your answer. I will try, the code is huge and proprietary, so
it will take some time before i can reproduce the problem independently.

On Fri, Sep 11, 2015 at 12:29 PM, Shlomi Fish <shlomif@shlomifish.org>
wrote:

> https://bugs.kde.org/show_bug.cgi?id=352549
>
> Shlomi Fish <shlomif@shlomifish.org> changed:
>
>            What    |Removed                     |Added
>
> ----------------------------------------------------------------------------
>                  CC|                            |shlomif@shlomifish.org
>
> --- Comment #1 from Shlomi Fish <shlomif@shlomifish.org> ---
> Hi!
>
> Can you provide the C or C++ sources for a self-contained, reproducing
> example
> (with build instructions)?
>
> --
> You are receiving this mail because:
> You reported the bug.
>

Comment 3 Florian Krohm 2015-09-11 12:26:12 UTC

(In reply to Achkan from comment #2)
> Created attachment 94508 [details]
> attachment-10926-0.html
> 
> Thank you for your answer. I will try, the code is huge and proprietary, so
> it will take some time before i can reproduce the problem independently.

There is no need to do that. This piece of information here:

vex amd64->IR: unhandled instruction bytes: 0xFF 0xFF 0xC5 0x79 0x6E 0xEA 0xC4 0x42

from the bug description is all that is needed. 

You could try valgrind development sources. Perhaps the bug has been fixed in the meantime.
In case it hasn't been fixed:
If you can find out what instruction that is, that would be helpful (and much less work for you).
Also of interest is, whether this is a 32-bit or 64-bit application.

Comment 4 Tom Hughes 2015-09-11 12:50:30 UTC

The double FF at the start looks pretty odd to me... What's after that is an AVX instruction of some sort though.

Comment 5 Tom Hughes 2015-09-11 12:53:31 UTC

Well FF in the first byte would mean a group 5 instruction but having bits 3, 4 and 5 all be 1 in the next byte appears to be undefined.

Comment 6 Tom Hughes 2015-09-11 12:59:46 UTC

What follows doesn't seem to make much more sense - if I'm reading it right that 0xC5 0x79 0x6E is a VEX encoded version of 0x66 0x6E which is an OUTS instruction.

I'm pretty sure you're not actually executing read code - either you have jumped through a bogus pointer or you're doing on the fly code generation and don't have --smc-check set right.

Comment 7 Julian Seward 2016-09-15 11:58:42 UTC

Per Tom's analysis, I don't think this is valid.  Looks like an application bug
to me.  Closing as invalid.  If you have more information, please feel free to
reopen.