[x264-devel] SIGBUS ("Bus error") on ARMv7 for video encoding with libx264

[Janne Grunau]

Hi,

On 2015-12-30 13:22:59 +0100, Maximilian Strauch wrote:
> 
> I  tried to encode a video using FFmpeg on my ODROID-XU4 (ARMv7) and 
> got a „Bus error.“. I already created an bug report in the FFmpeg bug 
> tracker [1], but they directed my to here.
> 
> I attached three files to this mail:
>  - cpuinfo.txt — only showing the details of the CPU
>  - gdb.txt — the debugging output of GNU debugger
>  - log.txt — the FFmepg verbose output log
> 
> Using the web I figured out that there is some kind of misaligned 
> memory access going on which is then catcher by the CPU because it ist 
> forbidden on ARMv7 (??). I think the most important part from the GDB 
> output is:
> 
> {{
> 0x0084880c in x264_mbtree_propagate_list_internal_neon ()
> (gdb) bt
> #0  0x0084880c in x264_mbtree_propagate_list_internal_neon ()
> #1  0x0083fb4e in x264_mbtree_propagate_list_neon ()
> #2  0x007fdd54 in x264_macroblock_tree_propagate.constprop ()
> #3  0xa320798c in ?? ()
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> (gdb) disass $pc-32,$pc+32
> Dump of assembler code from 0x8487ec to 0x84882c:
>    0x008487ec <x264_mbtree_propagate_list_internal_neon+20>:	vmov.i32	q11, #4	; 0x00000004
>    0x008487f0 <x264_mbtree_propagate_list_internal_neon+24>:	vmov.i8	q3, #32	; 0x20
>    0x008487f4 <x264_mbtree_propagate_list_internal_neon+28>:	vdup.16	q8, d5[0]
>    0x008487f8 <x264_mbtree_propagate_list_internal_neon+32>:	vzip.16	q0, q8
>    0x008487fc <x264_mbtree_propagate_list_internal_neon+36>:	ldr	r12, [sp, #8]
>    0x00848800 <x264_mbtree_propagate_list_internal_neon+40>:	subs	r12, r12, #8
>    0x00848804 <x264_mbtree_propagate_list_internal_neon+44>:	vld1.16	{d28-d29}, [r1 :128]!
>    0x00848808 <x264_mbtree_propagate_list_internal_neon+48>:	vld1.16	{d30-d31}, [r2 :128]!
> => 0x0084880c <x264_mbtree_propagate_list_internal_neon+52>:	vld1.16	{d16-d19}, [r0 :128]!

indeed. that would have been enough. The bug is already fixed in in 
https://git.videolan.org/?p=x264/x264-sandbox.git;a=commitdiff;h=a2fe237af1b68f2bd53d64ed3faed62429d3ee5a 
and should be available in x264 main repository in the next days.

[...]
 
> At a place in the web [2] I found that the error might be triggered by 
> " ld1.16 {d28-d29}, [r1 :128]!" which "requires that the base address 
> [be] is at least 128-bit aligned“ and that removing this „:128“ part 
> will solve the issue but maybe destroy the algorithm. So I ask you for 
> help, please!

That is the correct fix as you can see in above commit. Removing an 
alignment specifier won't change the algorithm or results. It only makes 
loads/store slower.

HTH Janne