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

[Maximilian Strauch]

Hello,

>>   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.

I’ve patched my source version of x264 with this fix and recompiled it together with ffmpeg and it works fine. Which difference two lines can make …

> 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.

It would have taken me at least three to four days to get so deep into ARM assembly to understand it and come to this conclusion. So thank you for solving this issue.

Greetings,
Max