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 > ------------------------------------------------------------------------------ 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
