[x264-devel] Crash due to unaligned pointer on SPARC
Jason Garrett-Glaser
darkshikari at gmail.com
Fri Jan 30 21:20:07 CET 2009
2009/1/28 Doctor Jones <document5 at lycos.com>:
> Under my Debian Lenny RC1 SPARC machine, every snapshot of x264 that I have tried crashes with "Bus error" when attempting to encode a file. This happens both with the shared library (through mencoder and ffmpeg at least) and the x264 command line encoder.
>
> I think I have tracked down the issue. I'm new to this, so if I'm incredibly wrong don't hesitate to say it. I think it's related to an unaligned memory access. I've been poking around with gdb for a while (various gdb outputs attached at bottom), and the crash looks like this:
>
> Of particular note is that s->p is not properly byte aligned at the time of the crash. I believe this is the cause.
>
> [Thread debugging using libthread_db enabled]
> x264 [info]: using cpu capabilities: none!
> p_bitstream is 0xf793e020
> x264 [info]: profile Main, level 3.0
> [New Thread 0xf7f93350 (LWP 4644)]
>
> Program received signal SIGBUS, Bus error.
> [Switching to Thread 0xf7f93350 (LWP 4644)]
> 0x00071094 in x264_sps_write (s=0xa07c8, sps=0xa0808) at ./common/bs.h:123
> 123 *(uint32_t*)s->p = endian_fix( s->cur_bits );
> (gdb) print s->p
> $1 = (uint8_t *) 0xf793e209 ""
> (gdb) bt
> #0 0x00071094 in x264_sps_write (s=0xa07c8, sps=0xa0808) at ./common/bs.h:123
> #1 0x0001fa8c in x264_encoder_encode (h=0xa0300, pp_nal=0xfff6721c, pi_nal=0xfff67218, pic_in=0xfff67580,
> pic_out=0xfff67220) at encoder/encoder.c:1580
> #2 0x000121a8 in Encode_frame (h=0xa0300, hout=0xa0008, pic=0xfff67580) at x264.c:757
> #3 0x00012eb0 in main (argc=<value optimized out>, argv=0xfff67904) at x264.c:841
> (gdb) disass $pc-32 $pc+32
> Dump of assembler code from 0x71074 to 0x710b4:
> 0x00071074 <x264_sps_write+2196>: ld [ %i0 + 0xc ], %g1
> 0x00071078 <x264_sps_write+2200>: sll %g1, %g3, %g1
> 0x0007107c <x264_sps_write+2204>: st %g1, [ %i0 + 0xc ]
> 0x00071080 <x264_sps_write+2208>: sub %g4, %g3, %g1
> 0x00071084 <x264_sps_write+2212>: b 0x710b4 <x264_sps_write+2260>
> 0x00071088 <x264_sps_write+2216>: st %g1, [ %i0 + 0x10 ]
> 0x0007108c <x264_sps_write+2220>: sll %g1, %g4, %g1
> 0x00071090 <x264_sps_write+2224>: ld [ %i0 + 4 ], %g2
> 0x00071094 <x264_sps_write+2228>: st %g1, [ %g2 ]
> 0x00071098 <x264_sps_write+2232>: ld [ %i0 + 4 ], %g1
> 0x0007109c <x264_sps_write+2236>: add %g1, 4, %g1
> 0x000710a0 <x264_sps_write+2240>: st %g1, [ %i0 + 4 ]
> 0x000710a4 <x264_sps_write+2244>: clr [ %i0 + 0xc ]
> 0x000710a8 <x264_sps_write+2248>: sub %g4, %g3, %g1
> 0x000710ac <x264_sps_write+2252>: add %g1, 0x20, %g1
> 0x000710b0 <x264_sps_write+2256>: st %g1, [ %i0 + 0x10 ]
> End of assembler dump.
> (gdb) info all-registers
> g0 0x0 0
> g1 0x4d401e9a 1296047770
> g2 0xf793e209 -141303287
> g3 0x2 2
> g4 0x1 1
> g5 0x0 0
> g6 0x3300474c 855656268
> g7 0xf7f93350 -134663344
> o0 0x99c9c 629916
> o1 0x0 0
> o2 0x0 0
> o3 0x0 0
> o4 0x7 7
> o5 0x7 7
> sp 0xfff67030 0xfff67030
> o7 0x707e8 460776
> l0 0x0 0
> l1 0x0 0
> l2 0x0 0
> l3 0x0 0
> l4 0x0 0
> l5 0x0 0
> l6 0x0 0
> ---Type <return> to continue, or q <return> to quit---
> l7 0x0 0
> i0 0xa07c8 657352
> i1 0xa0808 657416
> i2 0x3 3
> i3 0xa0ce4 658660
> i4 0x0 0
> i5 0x0 0
> fp 0xfff670a0 0xfff670a0
> i7 0x1fa84 129668
> f0 2.81690598 (raw 0x40344830)
> f1 1.85467776e-29 (raw 0x0fbc1630)
> f2 -nan(0x7fffff) (raw 0xffffffff)
> f3 -nan(0x7fffff) (raw 0xffffffff)
> f4 -nan(0x7fffff) (raw 0xffffffff)
> f5 -nan(0x7fffff) (raw 0xffffffff)
> f6 1.69999993 (raw 0x3fd99999)
> f7 -0 (raw 0x80000000)
> f8 1.875 (raw 0x3ff00000)
> f9 0 (raw 0x00000000)
> f10 1.875 (raw 0x3ff00000)
> f11 0 (raw 0x00000000)
> f12 0.0144915329 (raw 0x3c6d6de5)
> f13 7.57048119e+34 (raw 0x79694891)
> ---Type <return> to continue, or q <return> to quit---
> f14 0.408562958 (raw 0x3ed12f2a)
> f15 2.18561172 (raw 0x400be110)
> f16 0.408563018 (raw 0x3ed12f2c)
> f17 -1.90701462e-32 (raw 0x8ac60925)
> f18 0 (raw 0x00000000)
> f19 0 (raw 0x00000000)
> f20 -0.00686295424 (raw 0xbbe0e2a2)
> f21 -1.05229209e+12 (raw 0xd375017f)
> f22 0.46875 (raw 0x3ef00000)
> f23 0 (raw 0x00000000)
> f24 0.771456778 (raw 0x3f457e31)
> f25 -2.98926663e+31 (raw 0xf3bca635)
> f26 1.63148248 (raw 0x3fd0d46b)
> f27 3.40224056e+14 (raw 0x579ab74b)
> f28 0.0427142903 (raw 0x3d2ef52e)
> f29 3.14914689e+30 (raw 0x721efdc5)
> f30 1.81706607 (raw 0x3fe8959f)
> f31 -2.90170261e+12 (raw 0xd428e6bd)
> y 0x0 0
> psr 0xff000082 [ #1 S #24 #25 #26 #27 #28 #29 #30 #31 ]
> wim 0x0 0
> tbr 0x0 0
> pc 0x71094 0x71094 <x264_sps_write+2228>
> ---Type <return> to continue, or q <return> to quit---
> npc 0x71098 0x71098 <x264_sps_write+2232>
> fsr 0x0 [ ]
> csr 0x0 0
> d0 20.281983359737012 (raw 0x403448300fbc1630)
> d2 -nan(0xfffffffffffff) (raw 0xffffffffffffffff)
> d4 -nan(0xfffffffffffff) (raw 0xffffffffffffffff)
> d6 0.39999997615814209 (raw 0x3fd9999980000000)
> d8 1 (raw 0x3ff0000000000000)
> d10 1 (raw 0x3ff0000000000000)
> d12 1.276291691662309e-17 (raw 0x3c6d6de579694891)
> d14 4.0970417109975149e-06 (raw 0x3ed12f2a400be110)
> d16 4.0970500488921436e-06 (raw 0x3ed12f2c8ac60925)
> d18 0 (raw 0x0000000000000000)
> d20 -2.8604805813190531e-20 (raw 0xbbe0e2a2d375017f)
> d22 1.52587890625e-05 (raw 0x3ef0000000000000)
> d24 0.00065591277186633509 (raw 0x3f457e31f3bca635)
> d26 0.26296504550088134 (raw 0x3fd0d46b579ab74b)
> d28 5.4991993104000338e-14 (raw 0x3d2ef52e721efdc5)
> d30 0.76826468884902221 (raw 0x3fe8959fd428e6bd)
>
> But where does it go wrong? Well, it looks like it's here:
>
> Old value = (uint8_t *) 0xf78f2204 ".00"
> New value = (uint8_t *) 0xf78f2208 ""
> x264_sei_version_write (h=<value optimized out>, s=0xa07c8) at ./common/bs.h:125
> 125 s->cur_bits = i_bits;
> (gdb)
> Continuing.
> Watchpoint 9: s->p
>
> Old value = (uint8_t *) 0xf78f2208 "\200"
> New value = (uint8_t *) 0xf78f2209 ""
> x264_sei_version_write (h=<value optimized out>, s=0xa07c8) at ./common/bs.h:92
> 92 s->i_left = WORD_SIZE*8;
>
> That is, it looks like it's a result of
>
> s->p += WORD_SIZE - s->i_left / 8;
>
> in bs_flush (common/bs.h). This function includes a note that it will result in a stream that is no longer 32/64 bit aligned, but what can be done about it to prevent this crash on SPARC? I don't know enough about the code. Is there any reasonable way to maintain alignment?
The proper solution, I think, was posted a few days ago in a patch on
this ML--when initializing the bitstream, check the alignment, and
load the bits from whatever the unaligned portion of the bitstream is
back into the temporary bitstream variable, thus keeping the bitstream
pointer aligned.
This might help performance on x86 as well if it works. Try testing it.
Dark Shikari
More information about the x264-devel
mailing list