SRU Justification:
[Impact]
* A segfault in libx264-123 has caused major regressions in vlc, kazam, avidemux, and avconv among others. Nearly any program that encodes video in H264 is probably affected.
[Test Case]
* As this impacts many packages, there are a number of possible test cases. A simple one is to use kazam, the screen recording app:
1) Install the kazam package.
2) Run kazam
3) Make sure "file > preferences > screencast > record with" is set to H264/MP4
4) Attempt to record a screencast.
With 2:0.123.2189+git35cf912-1ubuntu1 from saucy install, you will experience a segfault. With the version in saucy-proposed, a screencast will be correctly recorded and encoded.
[Regression Potential]
* There is little chance of regression. In order to make the most minimal change possible, the package is just simply built with -fno-aggressive-loop-optimizations rather than attempting to backport any code changes from upstream. The most likely regression would be a typo causing a FTBFS (though I have built and tested the package on saucy).
[Other Info]
This had not been rebuilt with gcc 4.8 until one day before release when a rebuilt was triggered to fix the arm64 build.
http://gcc.gnu.org/gcc-4.8/changes.html
"GCC now uses a more aggressive analysis to derive an upper bound for the number of iterations of loops using constraints imposed by language standards. This may cause non-conforming programs to no longer work as expected, such as SPEC CPU 2006 464.h264ref and 416.gamess. A new option, -fno-aggressive-loop-optimizations, was added to disable this aggressive analysis. In some loops that have known constant number of iterations, but undefined behavior is known to occur in the loop before reaching or during the last iteration, GCC will warn about the undefined behavior in the loop instead of deriving lower upper bound of the number of iterations for the loop. The warning can be disabled with -Wno-aggressive-loop-optimizations."
The fix has already been uploaded to trusty.
-----------------------
Original bug:
Vlc crashes when encoding h264:
Thread 9 (Thread 0x7fffd9712700 (LWP 3034)):
#0 __memcmp_sse2 () at ../sysdeps/x86_64/multiarch/../memcmp.S:74
#1 0x00007fffc9ec9d9e in x264_cqm_init () from /usr/lib/x86_64-linux-gnu/libx264.so.123
#2 0x00007fffc9f34374 in x264_encoder_open_123 () from /usr/lib/x86_64-linux-gnu/libx264.so.123
#3 0x00007fffca1fef34 in Open (p_this=0x7fffd0000e08) at x264.c:1254
#4 0x00007ffff795ed00 in vlc_module_load (p_this=p_this@entry=0x7fffd0000e08,
psz_capability=psz_capability@entry=0x7fffe8ceaa31 "encoder", psz_name=<optimized out>, b_strict=b_strict@entry=true,
probe=probe@entry=0x7ffff795e5d0 <generic_start>) at modules/modules.c:347
#5 0x00007ffff795f1a4 in module_need (obj=obj@entry=0x7fffd0000e08, cap=cap@entry=0x7fffe8ceaa31 "encoder", name=<optimized out>,
strict=strict@entry=true) at modules/modules.c:437
#6 0x00007fffe8ce8a34 in transcode_video_new (p_stream=p_stream@entry=0x7fffe00059d8, id=id@entry=0x7fffd00008e0) at video.c:241
#7 0x00007fffe8ce9c28 in transcode_video_add (p_stream=p_stream@entry=0x7fffe00059d8, p_fmt=p_fmt@entry=0x7fffe0526990,
id=id@entry=0x7fffd00008e0) at video.c:832
#8 0x00007fffe8ce54a8 in Add (p_stream=0x7fffe00059d8, p_fmt=0x7fffe0526990) at transcode.c:553
#9 0x00007ffff797f64f in sout_InputNew (p_sout=0x7fffe000a6d8, p_fmt=p_fmt@entry=0x7fffe0526990)
at stream_output/stream_output.c:184
#10 0x00007ffff791b6e6 in DecoderProcessSout (p_block=0x0, p_dec=0x7fffe0523ea8) at input/decoder.c:1812
#11 DecoderProcess (p_dec=p_dec@entry=0x7fffe0523ea8, p_block=p_block@entry=0x7fffe052e9d0) at input/decoder.c:2040
#12 0x00007ffff791bde4 in DecoderThread (p_data=0x7fffe0523ea8) at input/decoder.c:938
#13 0x00007ffff76c8f6e in start_thread (arg=0x7fffd9712700) at pthread_create.c:311
#14 0x00007ffff71ef9cd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113
http://forum.doom9.org/showthread.php?p=1623567:
Configure x264 with "--extra-cflags=-fno-aggressive-loop-optimizations" solves this problem.
Also seems that problem solved in trunk - http://git.videolan.org/?p=x264.git;a=commit;h=89aecb440e2939be7fb72d8362eb12504711b94f
Status changed to 'Confirmed' because the bug affects multiple users.