Re: [Valgrind-users] VEX : unhandled instruction bytes

[Chris J. <jo...@he...>]

Hi,

On 05/08/14 11:52, Tom Hughes wrote:
> On 05/08/14 10:08, Chris Jones wrote:
>
>> I have an application that is causing valgrind to seg. fault, but runs
>> just fine natively. The seg. fault is below. This is using the SVN trunk
>> build of valgrind as of an hour or so ago (revision 14231).
>>
>> The primary message to me seems to be
>>
>> vex amd64->IR: unhandled instruction bytes: 0xFF 0xFF 0xFF 0xFF 0xFF
>> 0xFF 0xFF 0xFF
>> 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
>>
>> http://valgrind.org/docs/manual/faq.html
>>
>> Seems to suggest this could be one of two things; an error in the
>> application (but then it runs fine outside valgrind) or an error in
>> valgrind. Does anyone have any insights into which one this is here ?
>
> Firstly that's not a seg fault.

yes, my mistake. The seg. fault I was referring to was from a test with 
valgrind 3.8.1. Moving to 3.9.x removed this, but I erroneously still 
mentioned it above.

  It's a valgrind error telling you it has
> been asked to execute code that it can't make sense of.

Yep, figured that much.

>
> That's not really surprising given that I'm pretty sure that a string of
> 0xff bytes is not a valid x86 instruction.

Struck me as odd as well.

>
> Fortunately valgrind has already told you exactly where the problem is:
>
>> ==23684== Jump to the invalid address stated on the next line
>> ==23684==    at 0x2F769650: ???
>> ==23684==    by 0xFFEFEFFEF: ???
>> ==23684==    by 0x13E72601: ???
>> ==23684==    by 0x1151A3FF: ???
>> ==23684==    by 0x12E89588: clang::Decl::getASTContext() const (in
>> /afs/cern.ch/sw/lcg/releases/ROOT/6.00.02-1c3e2/x86_64-slc6-gcc48-opt/lib/libCling.so)
>
> So you have jumped to an invalid address at 0x2f769650...
>
>> ==23684==  Address 0x2f769650 is 0 bytes inside a block of size 32 alloc'd
>> ==23684==    at 0x4A07FD5: operator new(unsigned long)
>> (vg_replace_malloc.c:326)
>> ==23684==    by 0x13E725DB: ???
>> ==23684==    by 0x125E3AE5: TClingCallFunc::exec(void*, void*) const (in
>> /afs/cern.ch/sw/lcg/releases/ROOT/6.00.02-1c3e2/x86_64-slc6-gcc48-opt/lib/libCling.so)
>
> ...and that address is in a block of dynamically allocated memory.

Yeah, I guess that was clear, I just didn't focus on them enough.

> Which means that you are presumably dealing with a program that
> generates code on the fly, and you will need to use --smc-check to tell
> valgrind where it should expect the find self modifying code like this.
>
> It defaults to only checking for it on the stack, so you will probably
> need to change it by using --smc-check=all-non-file so that it will
> check the heap as well. That will slow things down a bit but it should
> hopefully solve your problem.

Yes, this sounds very likely. Cling as I said is an interactive compiler 
environment and as such definitely will be doing this. We will try the 
option you suggest.

thanks for the help.

Chris

>
> Tom
>