Bug#872503: ffmpeg: armhf SIGBUS in ff_diff_pixels_armv6 running winff autopkgtest

[Carl Eugen Hoyos]

Michael has committed a patch that is supposed to fix this crash:
http://ffmpeg.org/pipermail/ffmpeg-cvslog/2017-August/108709.html

Thank you for the useful report!

Carl Eugen

Bug#872503: ffmpeg: armhf SIGBUS in ff_diff_pixels_armv6 running winff autopkgtest

[James Cowgill]

Hi,

On 19/08/17 21:20, Carl Eugen Hoyos wrote:
>> Am 19.08.2017 um 20:26 schrieb James Cowgill :
>>> On 19/08/17 10:36, Carl Eugen Hoyos wrote:
>>> Could you confirm that this is a regression since 31326143 (ie since
>>> forever) and is not reproducible with f73a626a?
>>
>> Yes the code fails in the same place with 31326143 and worlds with
>> f73a626a, although I don't think the ARM code is at fault here since the
>> misaligned argument is coming from further up the call chain.
> 
> (Not so sure: The new functions with stricter requirements are meant as 
> replacement for functions with lower requirements.)

pixblockdsp.h says "align 8" next to s2 which I assume means that the
caller will guarantee the argument is aligned to 8 bytes. It wasn't
aligned in this case which is why the ARM code blew up.

> Thanks again for the very complete tests!
> 
>>> Since I cannot produce the required gdb output, you will have to open
>>> a ticket, sorry!
>>
>> OK. I'll see if the arguments are misaligned on x86 as well first.
> 
> Probably, but that doesn't hurt or does it?

I can reproduce the misalignment on x86 as well. x86 handles misaligned
addresses (with a performance penalty) which is probably why it doesn't
crash there.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#872503: ffmpeg: armhf SIGBUS in ff_diff_pixels_armv6 running winff autopkgtest

[James Cowgill]

Hi,

On 19/08/17 10:36, Carl Eugen Hoyos wrote:
> 2017-08-18 19:17 GMT+02:00 Carl Eugen Hoyos :
>> 2017-08-18 14:08 GMT+02:00 James Cowgill :
>>> Control: tags -1 upstream
>>
>> (Sorry if I misunderstand: Not sure if I am "upstream")

To clarify, the tag doesn't mean that you are upstream. It means that
this bug is an upstream bug, as opposed to something Debian specific.

>>> Hi,
>>>
>>> On 18/08/17 08:25, Carl Eugen Hoyos wrote:
 Hi!

 Is this issue still reproducible with current FFmpeg git head?
>>>
>>> I've just tested and yes it is still reproducible with this commit:
>>
>> Thank you!
>>
>> I will try to test next week on an Android device, feel free to open a
>> ticket on trac.ffmpeg.org - I am not sure how active the arm support
>> is though;-(
> 
> I can reproduce a crash on Android with the following command line:
> $ ffmpeg -i test.avi -cmp dct -an out.flv
> 
> Unfortunately, I was unable to get any useful gdb output and cannot
> verify that I see the same crash you reported:
> I managed to get a core dump and copied it to my build system, but
> Android gdb could not get a backtrace there;-(

Unfortunately as I wrote in the original report, the ARM code reuses the
lr register so you can't get a backtrace from where the code gets the
SIGBUS.

> Could you confirm that this is a regression since 31326143 (ie since
> forever) and is not reproducible with f73a626a?

Yes the code fails in the same place with 31326143 and worlds with
f73a626a, although I don't think the ARM code is at fault here since the
misaligned argument is coming from further up the call chain.

> Since I cannot produce the required gdb output, you will have to open
> a ticket, sorry!

OK. I'll see if the arguments are misaligned on x86 as well first.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#872503: ffmpeg: armhf SIGBUS in ff_diff_pixels_armv6 running winff autopkgtest

[Carl Eugen Hoyos]

I suspect this is a regression since 31326143 (when the function was added).

Carl Eugen

Bug#872503: ffmpeg: armhf SIGBUS in ff_diff_pixels_armv6 running winff autopkgtest

[James Cowgill]

Control: tags -1 upstream

Hi,

On 18/08/17 08:25, Carl Eugen Hoyos wrote:
> Hi!
> 
> Is this issue still reproducible with current FFmpeg git head?

I've just tested and yes it is still reproducible with this commit:

commit f4544163b27615ecfff1b42d6acdb3672ac92399
Author: Jacob Trimble 
AuthorDate: Thu Jul 27 10:34:32 2017 -0700
Commit: Michael Niedermayer 
CommitDate: Fri Aug 18 03:02:11 2017 +0200

 libavformat/mov: Fix inserting frames before current_frame.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#872503: ffmpeg: armhf SIGBUS in ff_diff_pixels_armv6 running winff autopkgtest

[Carl Eugen Hoyos]

Hi!

Is this issue still reproducible with current FFmpeg git head?

Carl Eugen

Bug#872503: ffmpeg: armhf SIGBUS in ff_diff_pixels_armv6 running winff autopkgtest

[James Cowgill]

Source: ffmpeg
Version: 7:3.3.3-3
Severity: important
Control: found -1 7:3.2.4-1
Control: affects -1 src:winff

Hi,

Just noticed that winff's autopkgtests fail on armhf because ffmpeg
receives a SIGBUS.

The failing command is:

> /usr/bin/ffmpeg -i test.avi -vcodec flv -f flv -r 29.97 -vf scale=w=320:h=240 
> -aspect 4:3 -b:v 300k -g 160 -cmp dct -subcmp dct -mbd 2 -flags +aic+mv0+mv4 
> -trellis 1 -ac 1 -ar 22050 -b:a 56k -y -t 1 test.flv

Where test.avi can be obtained from the winff source package:
https://sources.debian.net/src/winff/1.5.5-1/debian/tests/test.avi/

Backtrace:
> (gdb) bt
> #0  ff_diff_pixels_armv6 () at src/libavcodec/arm/pixblockdsp_armv6.S:46
> #1  0xf6540fe8 in dct_sad8x8_c (h=8, stride=352,
> src2=0xaacf377f 
> "ddefhiiihmmmnnnoopqqruuuvvvwwyyz{{|}}\200\200\201\201\202\203\203\203\202\202\202\203\203\203\204\204\206\205\205\204\204\203\203\203\200\201\201\201\201\202\202\202\206\206\206\206\206\206\206\206\210\212\215\220\222\222\221\220\220\220\220\221\221\222\222\222\223\223\224\225\225\226\226\227\235\235\236\236\236",
>  '\237' , 
> "\240\240\241\241\242\242\243\243\243\244\245\245\246\246\247\250\250\251\251\252\252\253\251\251\252\252\252\253\253\253\255\255\255\255\255\255\255\255\256\256\257\257\257\260\260\260\261\261\261\261\261\261\261\261\263\263\263\264\264\264\265\265\264\264\264\264\264\264\264"...,
> src1=0xaadf6990 
> "bcegijjkkklononnnmnnnoppqqqrvvuuuvwxy{|~~\177\200\201\201\202\203\202\202\203\204\204\204\204\205\205\206\206\206\206\205\205\205\204\203\203\203\202\202\202\202\202\203\204\204\205\205\207\211\210\211\213\215\220\222\222\221\221\221\221\220\220\220\220\221\223\223\224\225\226\225\225\225\227\232\233\234\235\235\234\234\235\235\235\236\237\236\237\240\237\236\236\237\237\237\240\241\241\241\241\242\243\243\243\244\245\244\245\246\246\246\247\247\250\251\252\253\253\253\253\252\252\254\254\254\254\254\255\255\256\257\257\257\257\257\257\257\257\260\260\261\262\262\261\260\261\261\262\262\262\263\264\264\264\264\264\264\264\264\264\264\263"...,
>  s=0xaac58b10) at src/libavcodec/me_cmp.c:631
> #2  dct_sad16_c (s=0xaac58b10,
> dst=0xaadf6990 
> "bcegijjkkklononnnmnnnoppqqqrvvuuuvwxy{|~~\177\200\201\201\202\203\202\202\203\204\204\204\204\205\205\206\206\206\206\205\205\205\204\203\203\203\202\202\202\202\202\203\204\204\205\205\207\211\210\211\213\215\220\222\222\221\221\221\221\220\220\220\220\221\223\223\224\225\226\225\225\225\227\232\233\234\235\235\234\234\235\235\235\236\237\236\237\240\237\236\236\237\237\237\240\241\241\241\241\242\243\243\243\244\245\244\245\246\246\246\247\247\250\251\252\253\253\253\253\252\252\254\254\254\254\254\255\255\256\257\257\257\257\257\257\257\257\260\260\261\262\262\261\260\261\261\262\262\262\263\264\264\264\264\264\264\264\264\264\264\263"...,
> src=0xaacf377f 
> "ddefhiiihmmmnnnoopqqruuuvvvwwyyz{{|}}\200\200\201\201\202\203\203\203\202\202\202\203\203\203\204\204\206\205\205\204\204\203\203\203\200\201\201\201\201\202\202\202\206\206\206\206\206\206\206\206\210\212\215\220\222\222\221\220\220\220\220\221\221\222\222\222\223\223\224\225\225\226\226\227\235\235\236\236\236",
>  '\237' , 
> "\240\240\241\241\242\242\243\243\243\244\245\245\246\246\247\250\250\251\251\252\252\253\251\251\252\252\252\253\253\253\255\255\255\255\255\255\255\255\256\256\257\257\257\260\260\260\261\261\261\261\261\261\261\261\263\263\263\264\264\264\265\265\264\264\264\264\264\264\264"...,
>  stride=352, h=16) at src/libavcodec/me_cmp.c:971
> #3  0xf6570cec in cmp_inline (chroma=0, qpel=0, chroma_cmp_func= out>, cmp_func=0x0, src_index=, ref_index=,
> h=16, size=0, suby=0, subx=0, y=, x=-1, s=0x0) at 
> src/libavcodec/motion_est.c:217
> #4  cmp_simple (chroma_cmp_func=, cmp_func=0x0, 
> src_index=, ref_index=, y=, 
> x=-1, s=0x0)
> at src/libavcodec/motion_est.c:234
> #5  cmp (flags=0, chroma_cmp_func=, cmp_func=0x0, 
> src_index=, ref_index=, h=16, size=0, suby=0, 
> subx=0,
> y=, x=-1, s=0x0) at src/libavcodec/motion_est.c:266
> #6  small_diamond_search (flags=0, h=16, size=0, penalty_factor=-16, 
> ref_index=240, src_index=2, dmin=, best=0xfffee064, s=0x0)
> at src/libavcodec/motion_est_template.c:445
> #7  diamond_search (flags=0, h=16, size=0, penalty_factor=-16, ref_index=240, 
> src_index=2, dmin=, best=0xfffee064, s=0x0)
> at src/libavcodec/motion_est_template.c:840
> #8  epzs_motion_search_internal (h=16, size=0, flags=0, ref_mv_scale=0, 
> last_mv=0x0, ref_index=-162058212, src_index=0, P=0xfffee01c,
> my_ptr=0xf77efce8 <__stack_chk_guard>, mx_ptr=0x15, s=0x1196a700) at 
> src/libavcodec/motion_est_template.c:966
> #9  ff_epzs_motion_search (s=0x1196a700, s@entry=0xaac58b10, mx_ptr=0x15, 
> mx_ptr@entry=0xfffee0e4, my_ptr=0xf77efce8 <__stack_chk_guard>,
> my_ptr@entry=0xfffee0e8, P=P@entry=0xfffee0ec, 
> src_index=src_index@entry=0, ref_index=ref_index@entry=0, last_mv=0xaaccf9b8, 
> ref_mv_scale=32768,
> ref_mv_scale@entry=65536,