On 03/08/17 14:07, James Cowgill wrote:
Source: ffmpeg
Version: 7:3.3.3-1
Severity: important
Tags: sid buster
X-Debbugs-CC: debian-...@lists.debian.org, binut...@packages.debian.org
Hi,
I was looking at the Ubuntu proposed migration pages for ffmpeg and
noticed that the autopkgtest failed on armhf:
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful/artful/armhf/f/ffmpeg/20170803_033623_bd98d@/log.gz
It fails with SIGBUS when running the h264 tests.
(gdb) bt
#0 0xf6456e12 in ff_h264_idct_add_neon () at
src/libavcodec/arm/h264idct_neon.S:24
#1 0xf6456f3c in ff_h264_idct_add16_neon () at
src/libavcodec/arm/h264idct_neon.S:118
#2 0xf659c88c in hl_decode_mb_idct_luma (p=<optimized out>, dest_y=<optimized out>,
linesize=<optimized out>, block_offset=<optimized out>, pixel_shift=0, transform_bypass=0,
simple=1,
mb_type=<optimized out>, sl=<optimized out>, h=<optimized out>) at
src/libavcodec/h264_mb.c:778
#3 hl_decode_mb_444_simple_8 (h=0xaab6ea00, sl=<optimized out>) at
src/libavcodec/h264_mb_template.c:349
#4 0xf65a471e in ff_h264_hl_decode_mb (h=h@entry=0xaab6ea00,
sl=sl@entry=0xaab7a080) at src/libavcodec/h264_mb.c:810
#5 0xf65b3670 in decode_slice (avctx=<optimized out>,
arg=arg@entry=0xaab7a080) at src/libavcodec/h264_slice.c:2553
#6 0xf65b45a6 in ff_h264_execute_decode_slices (h=h@entry=0xaab6ea00) at
src/libavcodec/h264_slice.c:2728
#7 0xf65b954a in decode_nal_units (buf_size=20, buf=0xaab35f00 "",
h=0xaab6ea00) at src/libavcodec/h264dec.c:715
#8 h264_decode_frame (avctx=0xaab0d850, data=0xaab0dc70, got_frame=0xaab38a2c,
avpkt=<optimized out>) at src/libavcodec/h264dec.c:1016
#9 0xf679c8e2 in frame_worker_thread (arg=0xaab38908) at
src/libavcodec/pthread_frame.c:199
#10 0xf61895e8 in start_thread () from /lib/arm-linux-gnueabihf/libpthread.so.0
#11 0xf612a57c in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
(gdb) print $pc
$1 = (void (*)()) 0xf6456e12 <ff_h264_idct_add_neon+2>
(gdb) disassemble
Dump of assembler code for function ff_h264_idct_add_neon:
0xf6456e10 <+0>: vld1.64 {d0-d3}, [r1 :128]
0xf6456e14 <+4>: vmov.i16 q15, #0 ; 0x0000
0xf6456e18 <+8>: vswp d1, d2
0xf6456e1c <+12>: vst1.16 {d30-d31}, [r1 :128]!
Notice that the program counter is misaligned - there is no instruction
at 0xf6456e12.
Since nothing has been changed in h264idct_neon.S for > 2 years, I
guessed a toolchain issue and sure enough there is a difference
between compiling the same file with binutils 2.28 and 2.29:
--- h264idct_neon-binutils-2.28-5 2017-08-03 12:48:07.560036237 +0000
+++ h264idct_neon-binutils-2.29-3 2017-08-03 12:47:43.666083113 +0000
@@ -89,8 +89,8 @@
118: f04f 0e00 movne.w lr, #0
11c: f1be 0f00 cmp.w lr, #0
120: bf14 ite ne
- 122: f2af 0e7f subwne lr, pc, #127 ; 0x7f
- 126: f2af 1e27 subweq lr, pc, #295 ; 0x127
+ 122: f2af 0e7e subwne lr, pc, #126 ; 0x7e
+ 126: f2af 1e26 subweq lr, pc, #294 ; 0x126
12a: 47f0 blx lr
12c: f1bc 0c01 subs.w ip, ip, #1
130: f101 0120 add.w r1, r1, #32
[...]
Could the ARM porters look and see if the assembly in h264idct_neon.S is
sane? If it is, this is probably a binutils bug.
While I haven't looked at the source the LSB of a code pointer indicates
whether the system is in arm mode or thumb mode. It looks like in the old
binary is performing a mode switch while in the new binary is not.
_______________________________________________
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
