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. Thanks, James
signature.asc
Description: OpenPGP digital signature
