Bug#870622: ffmpeg: autopkgtest SIGBUS on armhf with binutils 2.29

[James Cowgill]

Source: ffmpeg
Version: 7:3.3.3-1
Severity: important
Tags: sid buster
X-Debbugs-CC: debian-arm at lists.debian.org, binutils at 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 at entry=0xaab6ea00, sl=sl at entry=0xaab7a080) at src/libavcodec/h264_mb.c:810
> #5  0xf65b3670 in decode_slice (avctx=<optimized out>, arg=arg at entry=0xaab7a080) at src/libavcodec/h264_slice.c:2553
> #6  0xf65b45a6 in ff_h264_execute_decode_slices (h=h at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20170803/ef4a4bb1/attachment.sig>