I'm trying to hunt memory leaks in mencoder. Shortly after startup (before much real processing happens), I get: ==6078== Memcheck, a memory error detector ==6078== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. ==6078== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info ==6078== Command: ./mencoder /root/tmp/big_buck_bunny_720p_h264.mov -o /root/tmp/outtest.avi -oac lavc -ovc lavc -lavcopts vcodec=msmpeg4v2:keyint=30 ==6078== Parent PID: 4580 ==6078== vex x86->IR: unhandled instruction bytes: 0xC5 0xFB 0x2C 0x40 ==6078== valgrind: Unrecognised instruction at address 0x4189724. ==6078== at 0x4189724: parse_flag (in /root/sandbox/MPlayer_snap/mplayer-checkout-2017-05-24/mencoder) ==6078== by 0x41872BA: m_config_parse_option (in /root/sandbox/MPlayer_snap/mplayer-checkout-2017-05-24/mencoder) ==6078== by 0x4171DCC: m_config_parse_me_command_line (in /root/sandbox/MPlayer_snap/mplayer-checkout-2017-05-24/mencoder) ==6078== Your program just tried to execute an instruction that Valgrind ==6078== did not recognise. There are two possible reasons for this. ==6078== 1. Your program has a bug and erroneously jumped to a non-code ==6078== location. If you are running Memcheck and you just saw a ==6078== warning about a bad jump, it's probably your program's fault. ==6078== 2. The instruction is legitimate but Valgrind doesn't handle it, ==6078== i.e. it's Valgrind's fault. If you think this is the case or ==6078== you are not sure, please let us know and we'll try to fix it. ==6078== Either way, Valgrind will now raise a SIGILL signal which will ==6078== probably kill your program. ==6078== ==6078== Process terminating with default action of signal 4 (SIGILL): dumping core ==6078== Illegal opcode at address 0x4189724 ==6078== at 0x4189724: parse_flag (in /root/sandbox/MPlayer_snap/mplayer-checkout-2017-05-24/mencoder) ==6078== by 0x41872BA: m_config_parse_option (in /root/sandbox/MPlayer_snap/mplayer-checkout-2017-05-24/mencoder) ==6078== by 0x4171DCC: m_config_parse_me_command_line (in /root/sandbox/MPlayer_snap/mplayer-checkout-2017-05-24/mencoder) ==6078== ==6078== HEAP SUMMARY: ==6078== in use at exit: 64,311 bytes in 1,979 blocks ==6078== total heap usage: 2,021 allocs, 42 frees, 87,483 bytes allocated ==6078== ==6078== LEAK SUMMARY: ==6078== definitely lost: 0 bytes in 0 blocks ==6078== indirectly lost: 0 bytes in 0 blocks ==6078== possibly lost: 0 bytes in 0 blocks ==6078== still reachable: 64,311 bytes in 1,979 blocks ==6078== suppressed: 0 bytes in 0 blocks ==6078== Reachable blocks (those to which a pointer was found) are not shown. ==6078== To see them, rerun with: --leak-check=full --show-leak-kinds=all ==6078== ==6078== For counts of detected and suppressed errors, rerun with: -v ==6078== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 53 from 8)
The copy of mencoder was locally build with GCC 4.9.2 (as was valgrind).
You'll probably get a lot further if you use a 64 bit build - many of the newer instructions are not supported in 32 bit mode and that's likely to be a major issue in a media encoder that is likely to be using lots of SSE stuff.
(In reply to Tom Hughes from comment #2) > You'll probably get a lot further if you use a 64 bit build - many of the > newer instructions are not supported in 32 bit mode and that's likely to be > a major issue in a media encoder that is likely to be using lots of SSE > stuff. Ahh. I did try with an x64 build as well and also got an Illegal instruction (different instruction, still illegal). Am I more likely to see a fix for an x64 issue than an x32 one?
This should just work on 64-bit x86. It won't get fixed on 32-bit though.