Ran this by a Intel guy and he says this uses valid instructions. Any idea how to fix this? vex amd64->IR: unhandled instruction bytes: 0x48 0xF 0x5A 0x7 0x48 0xF 0x5A 0x4F ==30567== valgrind: Unrecognised instruction at address 0x886f810. ==30567== at 0x886F810: ??? (in /opt/intel/composerxe-2011.2.137/ipp/lib/intel64/libippsy8.so.7.0) ==30567== by 0x10E962D: Psychoacoustic (aac_enc_psychoacoustic_fp.c:483) ==30567== by 0x10DEF45: aacencGetFrame (aac_enc_api_fp.c:1141) ==30567== by 0x10DAB99: UMC::AACEncoder::GetFrame(UMC::MediaData*, UMC::MediaData*) (umc_aac_encoder.cpp:339) ==30567== by 0x87FB53: bm::rtp::AACPacketProcessor::send(bm::audio::LinearAudioUnit&) (aacpacketprocessor.cpp:173) ==30567== by 0x8E42BB: bm::Bridge::process(bm::events::bridge::OutboundLinearAudioUnit const&) (bridge.cpp:687) ==30567== by 0x8AC0E1: bm::events::bridge::OutboundLinearAudioUnit::processBy(bm::scheduling::Bus&) const (events.h:1053) ==30567== by 0x95A253: bm::scheduling::Bus::process(bm::events::Event const&) (bus.cpp:25) ==30567== by 0x8F6925: bm::Bridge::process(bm::events::Event&) (bridge.cpp:1659) ==30567== by 0x8ED68F: bm::Bridge::processExternalEvents(int, short) (bridge.cpp:1151) ==30567== by 0x8FB03F: bm::Bridge::processExternalEvents(int, short, void*) (bridge.cpp:1790) ==30567== by 0x52AAD18: event_base_loop (event.c:395) ==30567== by 0x8ECF30: bm::Bridge::run() (bridge.cpp:1065) ==30567== by 0x95A176: boost::_mfi::mf0<void, bm::Bridge>::operator()(bm::Bridge*) const (mem_fn_template.hpp:49) ==30567== by 0x95A06D: void boost::_bi::list1<boost::_bi::value<bm::Bridge*> >::operator()<boost::_mfi::mf0<void, bm::Bridge>, boost::_bi::list0>(boost::_bi::type<void>, boost::_mfi::mf0<void, bm::Bridge>&, boost::_bi::list0&, int) (bind.hpp:253) ==30567== by 0x959FD2: boost::_bi::bind_t<void, boost::_mfi::mf0<void, bm::Bridge>, boost::_bi::list1<boost::_bi::value<bm::Bridge*> > >::operator()() (bind_template.hpp:20) ==30567== by 0x9591B7: boost::detail::thread_data<boost::_bi::bind_t<void, boost::_mfi::mf0<void, bm::Bridge>, boost::_bi::list1<boost::_bi::value<bm::Bridge*> > > >::run() (thread.hpp:61) ==30567== by 0x54CDA54: thread_proxy (in /usr/lib64/libboost_thread-mt.so.1.44.0) ==30567== by 0x91D0CCA: start_thread (pthread_create.c:301) ==30567== by 0xBD26C2C: clone (clone.S:115) ==30567== Your program just tried to execute an instruction that Valgrind ==30567== did not recognise. There are two possible reasons for this. ==30567== 1. Your program has a bug and erroneously jumped to a non-code ==30567== location. If you are running Memcheck and you just saw a ==30567== warning about a bad jump, it's probably your program's fault. ==30567== 2. The instruction is legitimate but Valgrind doesn't handle it, ==30567== i.e. it's Valgrind's fault. If you think this is the case or ==30567== you are not sure, please let us know and we'll try to fix it. ==30567== Either way, Valgrind will now raise a SIGILL signal which will ==30567== probably kill your program. ==30567== ==30567== Process terminating with default action of signal 4 (SIGILL): dumping core ==30567== Illegal opcode at address 0x886F810 ==30567== at 0x886F810: ??? (in /opt/intel/composerxe-2011.2.137/ipp/lib/intel64/libippsy8.so.7.0) ==30567== by 0x10E962D: Psychoacoustic (aac_enc_psychoacoustic_fp.c:483) ==30567== by 0x10DEF45: aacencGetFrame (aac_enc_api_fp.c:1141) ==30567== by 0x10DAB99: UMC::AACEncoder::GetFrame(UMC::MediaData*, UMC::MediaData*) (umc_aac_encoder.cpp:339) ==30567== by 0x87FB53: bm::rtp::AACPacketProcessor::send(bm::audio::LinearAudioUnit&) (aacpacketprocessor.cpp:173) ==30567== by 0x8E42BB: bm::Bridge::process(bm::events::bridge::OutboundLinearAudioUnit const&) (bridge.cpp:687) ==30567== by 0x8AC0E1: bm::events::bridge::OutboundLinearAudioUnit::processBy(bm::scheduling::Bus&) const (events.h:1053) ==30567== by 0x95A253: bm::scheduling::Bus::process(bm::events::Event const&) (bus.cpp:25) ==30567== by 0x8F6925: bm::Bridge::process(bm::events::Event&) (bridge.cpp:1659) ==30567== by 0x8ED68F: bm::Bridge::processExternalEvents(int, short) (bridge.cpp:1151) ==30567== by 0x8FB03F: bm::Bridge::processExternalEvents(int, short, void*) (bridge.cpp:1790) ==30567== by 0x52AAD18: event_base_loop (event.c:395)
This is a CVTPS2PD instruction.
The problem is the 0x48 (REX.W) prefix which we're not expecting - it is likely redundant.
*** Bug 288274 has been marked as a duplicate of this bug. ***
Same here with valgrind 3.8.1: vex amd64->IR: unhandled instruction bytes: 0x48 0xF 0x5A 0x7 0x48 0xF 0x5A 0x4F vex amd64->IR: REX=1 REX.W=1 REX.R=0 REX.X=0 REX.B=0 vex amd64->IR: VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=0F vex amd64->IR: PFX.66=0 PFX.F2=0 PFX.F3=0
Created attachment 82243 [details] Fix relative to 3.8.1 release The attached minor change to guest_amd64_toIR.c resolves this issue for me when running with IPP under valgrind 3.8.1.
Created attachment 82244 [details] Fix relative to current SVN HEAD (r2755) And furthermore, here is a second patch which fixes this relative to the current SVN HEAD (r2755). There is no difference between the two patches other than the relevant line numbers.
I have the exact same output as Gaetano reported in comment #4. The patch from Griffin Myers works for me.
Created attachment 94921 [details] redundantRexW testcase extension for cvtps2pd I think ignoring the REX.W for cvtps2pd is correct. I cannot find anything that explains what it really means. Attached is an extension to the none/tests/amd64/redundantRexW testcase that seems to confirm it.
*** Bug 329245 has been marked as a duplicate of this bug. ***
VEX svn r3198 valgrind svn r15699