|
From: Mikhail K. <ka...@il...> - 2015-01-22 22:59:04
|
Simliar to http://sourceforge.net/p/valgrind/mailman/message/31947655/ I grabbed a copy of valgrind from SVN and I'm still having trouble with 0xC4 and callgrind. Is there some branch where this is fixed? Any suggestions? vex amd64->IR: unhandled instruction bytes: 0xC4 0xC2 0x7D 0x2E 0x8 0x49 0x83 0xC0 vex amd64->IR: REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=1 vex amd64->IR: VEX=1 VEX.L=1 VEX.nVVVV=0x0 ESC=0F38 vex amd64->IR: PFX.66=1 PFX.F2=0 PFX.F3=0 ==29091== valgrind: Unrecognised instruction at address 0x433c64. ==29091== at 0x433C64: ImgFetcher::getMat(std::string const&, cv::Mat&) (fetcher.cpp:44) ==29091== by 0x44CDE5: storeTrans(ImgFetcher&, cv::Point_<float> const&, std::map<std::array<std::array<int, 2ul>, 2ul>, TransData, std::less<std::array<std::array<int, 2ul>, 2ul> >, std::allocator<std::pair<std::array<std::array<int, 2ul>, 2ul> const, TransData> > >&, MaxDists const&) (translate.cpp:339) ==29091== by 0x416356: main (main.cpp:337) ==29091== Your program just tried to execute an instruction that Valgrind ==29091== did not recognise. There are two possible reasons for this. ==29091== 1. Your program has a bug and erroneously jumped to a non-code ==29091== location. If you are running Memcheck and you just saw a ==29091== warning about a bad jump, it's probably your program's fault. ==29091== 2. The instruction is legitimate but Valgrind doesn't handle it, ==29091== i.e. it's Valgrind's fault. If you think this is the case or ==29091== you are not sure, please let us know and we'll try to fix it. ==29091== Either way, Valgrind will now raise a SIGILL signal which will ==29091== probably kill your program. ==29091== ==29091== Process terminating with default action of signal 4 (SIGILL) ==29091== Illegal opcode at address 0x433C64 ==29091== at 0x433C64: ImgFetcher::getMat(std::string const&, cv::Mat&) (fetcher.cpp:44) ==29091== by 0x44CDE5: storeTrans(ImgFetcher&, cv::Point_<float> const&, std::map<std::array<std::array<int, 2ul>, 2ul>, TransData, std::less<std::array<std::array<int, 2ul>, 2ul> >, std::allocator<std::pair<std::array<std::array<int, 2ul>, 2ul> const, TransData> > >&, MaxDists const&) (translate.cpp:339) |
|
From: John R. <jr...@bi...> - 2015-01-23 01:01:27
|
> vex amd64->IR: unhandled instruction bytes: 0xC4 0xC2 0x7D 0x2E 0x8 0x49 0x83 0xC0
-----foo.S
.byte 0xC4,0xC2,0x7D,0x2E,0x8,0x49,0x83,0xC0
-----
$ gcc -c foo.S
$ gdb foo.o
(gdb) x/i 0
0x0: vmaskmovps %ymm1,%ymm0,(%r8)
> ==29091== 2. The instruction is legitimate but Valgrind doesn't handle it,
> ==29091== i.e. it's Valgrind's fault. If you think this is the case or
> ==29091== you are not sure, please let us know and we'll try to fix it.
File a bug [request for enhancement] at https://bugs.kde.org/enter_bug.cgi?product=valgrind .
Please mention the version of all software involved, which Linux distribution, etc.
In the meantime, use software which is not so highly optimized.
If that is your software, then remove "-O2", don't write assembly language, etc.
If that is an add-on shared library, then ask the supplier,
or change to an equivalent but not-so-optimized library.
If that is a built-in library such as [g]libc
then use a different Linux distribution which is not so aggressively optimized.
|