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. It's a valgrind error telling you it has been asked to execute code that it can't make sense of. That's not really surprising given that I'm pretty sure that a string of 0xff bytes is not a valid x86 instruction. 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. 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. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ------------------------------------------------------------------------------ Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
