[x264-devel] Segmentation fault on PandaBoard

[Jim Darby]

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/20120911/a7c287f3/attachment.html>