[x264-devel] Segmentation fault on PandaBoard

[Jim Darby]

I have some more information on this problem. Something is broken with 
the p4x4 partition with NEON.

I can set all the options for slower with the single exception of the 
p4x4 partition. So, in other words the command line:

x264 -o test.264 --preset slow --rc-lookahead 60 --ref 8 --subme 9 
--trellis 2 --partitions b8x8,i8x8,i4x4,p8x8 --input-res 720x576 test.yuv

works, but the command line:

x264 -o test.264 --preset slow --rc-lookahead 60 --ref 8 --subme 9 
--trellis 2 --partitions p4x4,p8x8 --input-res 720x576 test.yuv

doesn't (note p8x8 is needed for p4x4, even though they're called 16x16 
and 8x8 in the code).

Also the command line:

x264 -o test.264 --preset slow --partitions p4x4,p8x8 --input-res 
720x576 test.yuv

appears to fail faster!

Any ideas guys?

Jim.


On 11/09/12 18:15, Jim Darby wrote:
> I thought I'd give x264 a blast on the PandaBoard ES (see 
> http://pandaboard.org for details but essentially a dual-core 
> Cortex-A9 with NEON). I compiled it with no special options (even 
> though it sets the target machine to Cortex-A8).
>
> It encodes for a short while (5-10 seconds worth of video) and then 
> gets a segmentation fault. Recompiling with --debug and unwinding the 
> stack I can see that it blows up in mc_luma_neonbecause the weight 
> structpassed in from x264_me_refine_qpel_rdvia the COST_MV_SATD( bmx, 
> bmy, bsatd, 0 )macro called at encoder/me.c:1210 is an invalid pointer 
> (interestingly 0x53366970 which spells T69p in ascii). This weight 
> parameter comes from the m structure in x264_me_refine_qpel_rdwhich 
> has the same corrupted value.
>
> The command line was: x264 -o test.264 --preset slower --input-res 
> 720x576 test.yuv
>
> If I perform the same run with --no-asm it is amazingly slow but does 
> not appear to crash. This would appear to indicate some problem with 
> the NEON code. Running it single threaded doesn't help either.
>
> What does help is replacing the --preset slowerwith --preset slow. 
> /Now that's interesting!/ That limits us quite a lot as to what is 
> causing the problem.
>
> Any ideas on this one? More specifically, what can I do to help with 
> debugging this? I've avoided sending 126MB core files or detailed 
> backtraces but I'm very happy to do whatever is needed to help track 
> this down.
>
> As per the information on the web page, here is the gdb information:
>
> (gdb) bt
> #0  mc_luma_neon (dst=0x36ac78 "\345\331\325\327\331\343\344", 
> <incomplete sequence \345>, i_dst_stride=32, src=0xb5317254, 
> i_src_stride=784,
>     mvx=0, mvy=0, i_width=8, i_height=8, weight=0x53366a70) at 
> common/arm/mc-c.c:146
> #1  0x0005e0c6 in x264_me_refine_qpel_rd (h=0x365c60, m=0xb5317240, 
> i_lambda2=2322, i4=12, i_list=0) at encoder/me.c:1210
> #2  0x000563a4 in x264_macroblock_analyse (h=0x365c60) at 
> encoder/analyse.c:3362
> #3  0x0001f9b2 in x264_slice_write (h=0x365c60) at encoder/encoder.c:2309
> #4  0x0002057a in x264_slices_write (h=0x365c60) at encoder/encoder.c:2625
> #5  0x0002539e in x264_threadpool_thread (pool=0x3853a0) at 
> common/threadpool.c:69
> #6  0xb6e4fed2 in start_thread () from 
> /lib/arm-linux-gnueabihf/libpthread.so.0
> #7  0xb6de6058 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
> #8  0xb6de6058 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> (gdb) disass $pc-32,$pc+32
> Dump of assembler code from 0x71ff4 to 0x72034:
>    0x00071ff4 <mc_luma_neon+132>:       mov     r0, r5
>    0x00071ff6 <mc_luma_neon+134>:       mov     r1, r4
>    0x00071ff8 <mc_luma_neon+136>:       blx     r7
>    0x00071ffa <mc_luma_neon+138>:       ldr     r3, [r6, #44]   ; 0x2c
>    0x00071ffc <mc_luma_neon+140>:       cbz     r3, 0x7204a 
> <mc_luma_neon+218>
>    0x00071ffe <mc_luma_neon+142>:       str     r6, [sp, #0]
>    0x00072000 <mc_luma_neon+144>:       str.w   r8, [sp, #4]
>    0x00072004 <mc_luma_neon+148>:       ldr.w   r6, [r3, r9, lsl #2]
>    0x00072008 <mc_luma_neon+152>:       mov     r0, r5
>    0x0007200a <mc_luma_neon+154>:       mov     r1, r4
>    0x0007200c <mc_luma_neon+156>:       mov     r2, r5
>    0x0007200e <mc_luma_neon+158>:       mov     r3, r4
>    0x00072010 <mc_luma_neon+160>:       blx     r6
>    0x00072012 <mc_luma_neon+162>:       b.n     0x7204a <mc_luma_neon+218>
> => 0x00072014 <mc_luma_neon+164>:       ldr     r1, [r6, #44]   ; 0x2c
>    0x00072016 <mc_luma_neon+166>:       cbz     r1, 0x7202e 
> <mc_luma_neon+190>
>    0x00072018 <mc_luma_neon+168>:       mov.w   r9, r9, asr #2
>    0x0007201c <mc_luma_neon+172>:       str     r6, [sp, #0]
>    0x0007201e <mc_luma_neon+174>:       str.w   r8, [sp, #4]
>    0x00072022 <mc_luma_neon+178>:       ldr.w   r6, [r1, r9, lsl #2]
>    0x00072026 <mc_luma_neon+182>:       mov     r0, r5
>    0x00072028 <mc_luma_neon+184>:       mov     r1, r4
>    0x0007202a <mc_luma_neon+186>:       blx     r6
>    0x0007202c <mc_luma_neon+188>:       b.n     0x7204a <mc_luma_neon+218>
>    0x0007202e <mc_luma_neon+190>:       movw    r1, #42212      ; 0xa4e4
>    0x00072032 <mc_luma_neon+194>:       movt    r1, #8
> End of assembler dump.
> (gdb) info all-registers
> r0             0x0      0
> r1             0xb5317254       3039916628
> r2             0xb4b53172       3031773554
> r3             0x310    784
> r4             0x20     32
> r5             0x36ac78 3583096
> r6             0x53366a70       1396075120
> r7             0x0      0
> r8             0x8      8
> r9             0x8      8
> r10            0x3      3
> r11            0x0      0
> r12            0x0      0
> sp             0xb5316a48       0xb5316a48
> lr             0x0      0
> pc             0x72014  0x72014 <mc_luma_neon+164>
> cpsr           0x40000130       1073742128
>
> I've chopped off the rest of the registers as it very long and doesn't 
> seem to contain any relevant information.
>
> Cheers,
>
> Jim.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x264-devel/attachments/20120914/f50f9073/attachment.html>