Bug 380193

Summary:	vex x86->IR: unhandled instruction bytes: 0xC5 0xFB 0x2C 0x40 while running Memcheck on mencoder
Product:	[Developer tools] valgrind	Reporter:	Michael Kohne <mhkohne>
Component:	vex	Assignee:	Julian Seward <jseward>
Status:	RESOLVED INTENTIONAL
Severity:	crash	CC:	tom
Priority:	NOR
Version First Reported In:	3.12.0
Target Milestone:	---
Platform:	unspecified
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description Michael Kohne 2017-05-25 16:24:48 UTC

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)

Comment 1 Michael Kohne 2017-05-25 16:25:31 UTC

The copy of mencoder was locally build with GCC 4.9.2 (as was valgrind).

Comment 2 Tom Hughes 2017-05-25 17:07:52 UTC

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.

Comment 3 Michael Kohne 2017-05-26 17:27:19 UTC

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

Comment 4 Julian Seward 2018-07-24 12:01:45 UTC

This should just work on 64-bit x86.  It won't get fixed on 32-bit though.