<style> p {margin-top:0px;margin-bottom:0px;} </style> <table border=0 width=100%% cellpadding=0 cellspacing=0 align=center> <tr> <td valign=top style='padding:8pt;'><font size=2>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.<br><br>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:<br><br>Of particular note is that s->p is not properly byte aligned at the time of the crash. I believe this is the cause.<br><br>[Thread debugging using libthread_db enabled]<br>x264 [info]: using cpu capabilities: none!<br>p_bitstre!
am is 0xf793e020<br>x264 [info]: profile Main, level 3.0<br>[New Thread 0xf7f93350 (LWP 4644)]<br><br>Program received signal SIGBUS, Bus error.<br>[Switching to Thread 0xf7f93350 (LWP 4644)]<br>0x00071094 in x264_sps_write (s=0xa07c8, sps=0xa0808) at ./common/bs.h:123<br>123 *(uint32_t*)s->p = endian_fix( s->cur_bits );<br>(gdb) print s->p<br>$1 = (uint8_t *) 0xf793e209 ""<br>(gdb) bt<br>#0 0x00071094 in x264_sps_write (s=0xa07c8, sps=0xa0808) at ./common/bs.h:123<br>#1 0x0001fa8c in x264_encoder_encode (h=0xa0300, pp_nal=0xfff6721c, pi_nal=0xfff67218, pic_in=0xfff67580,<br> pic_out=0xfff67220) at encoder/encoder.c:1580<br>#2 0x000121a8 in Encode_frame (h=0xa0300, hout=0xa0008, pic=0xfff67580) at x264.c:757<br>#3 0x00012eb0 in main (argc=<value optimized out>, argv=0xfff67904) at x264.c:841<br>(gdb) disass $pc-32 $pc+32<br!
>Dump of assembler code from 0x71074 to 0x710b4:<br>0x00071074 <x26
4_sps_write+2196>: ld [ %i0 + 0xc ], %g1<br>0x00071078 <x264_sps_write+2200>: sll %g1, %g3, %g1<br>0x0007107c <x264_sps_write+2204>: st %g1, [ %i0 + 0xc ]<br>0x00071080 <x264_sps_write+2208>: sub %g4, %g3, %g1<br>0x00071084 <x264_sps_write+2212>: b 0x710b4 <x264_sps_write+2260><br>0x00071088 <x264_sps_write+2216>: st %g1, [ %i0 + 0x10 ]<br>0x0007108c <x264_sps_write+2220>: sll %g1, %g4, %g1<br>0x00071090 <x264_sps_write+2224>: ld [ %i0 + 4 ], %g2<br>0x00071094 <x264_sps_write+2228>: st %g1, [ %g2 ]<br>0x00071098 <x264_sps_write+2232>: &n!
bsp; ld [ %i0 + 4 ], %g1<br>0x0007109c <x264_sps_write+2236>: add %g1, 4, %g1<br>0x000710a0 <x264_sps_write+2240>: st %g1, [ %i0 + 4 ]<br>0x000710a4 <x264_sps_write+2244>: clr [ %i0 + 0xc ]<br>0x000710a8 <x264_sps_write+2248>: sub %g4, %g3, %g1<br>0x000710ac <x264_sps_write+2252>: add %g1, 0x20, %g1<br>0x000710b0 <x264_sps_write+2256>: st %g1, [ %i0 + 0x10 ]<br>End of assembler dump.<br>(gdb) info all-registers<br>g0 0x0 0<br>g1 0x4d401e9a 1296047770<br>g2!
&nbs
p; 0xf793e209 -141303287<br>g3 0x2 2<br>g4 0x1 1<br>g5 0x0 0<br>g6 0x3300474c 855656268<br>g7 0xf7f93350 -134663344<br>o0 0x99c9c 629916<br>o1 0x0 0<br>o2 0x0 &nb!
sp; 0<br>o3 0x0 0<br>o4 0x7 7<br>o5 0x7 7<br>sp 0xfff67030 0xfff67030<br>o7 0x707e8 460776<br>l0 0x0 0<br>l1 0x0 0<br>l2 0x0 0<br>l3 &nbs!
p; 0x0 0<br>l4 &n
bsp; 0x0 0<br>l5 0x0 0<br>l6 0x0 0<br>---Type <return> to continue, or q <return> to quit---<br>l7 0x0 0<br>i0 0xa07c8 657352<br>i1 0xa0808 657416<br>i2 0x3 3<br>i3 0xa0ce4 658660<br>i4 !
0x0 0<br>i5 0x0 0<br>fp 0xfff670a0 0xfff670a0<br>i7 0x1fa84 129668<br>f0 2.81690598 (raw 0x40344830)<br>f1 1.85467776e-29 (raw 0x0fbc1630)<br>f2 -nan(0x7fffff) (raw 0xffffffff)<br>f3 -nan(0x7fffff) (raw 0xffffffff)<br>f4 -nan!
(0x7fffff) (raw 0xffffffff)<br>f5 &
nbsp; -nan(0x7fffff) (raw 0xffffffff)<br>f6 1.69999993 (raw 0x3fd99999)<br>f7 -0 (raw 0x80000000)<br>f8 1.875 (raw 0x3ff00000)<br>f9 0 (raw 0x00000000)<br>f10 1.875 (raw 0x3ff00000)<br>f11 0 (raw 0x00000000)<br>f12 0.0144915329 (raw !
0x3c6d6de5)<br>f13 7.57048119e+34 (raw 0x79694891)<br>---Type <return> to continue, or q <return> to quit---<br>f14 0.408562958 (raw 0x3ed12f2a)<br>f15 2.18561172 (raw 0x400be110)<br>f16 0.408563018 (raw 0x3ed12f2c)<br>f17 -1.90701462e-32 (raw 0x8ac60925)<br>f18 0 (raw 0x00000000)<br>f19 0 (raw 0x00000000)<br>f20&n!
bsp; -0.00
686295424 (raw 0xbbe0e2a2)<br>f21 -1.05229209e+12 (raw 0xd375017f)<br>f22 0.46875 (raw 0x3ef00000)<br>f23 0 (raw 0x00000000)<br>f24 0.771456778 (raw 0x3f457e31)<br>f25 -2.98926663e+31 (raw 0xf3bca635)<br>f26 1.63148248 (raw 0x3fd0d46b)<br>f27 3.40224056e+14 (raw 0x579ab74b)<br>f28 0.0427142903  !
; (raw 0x3d2ef52e)<br>f29 3.14914689e+30 (raw 0x721efdc5)<br>f30 1.81706607 (raw 0x3fe8959f)<br>f31 -2.90170261e+12 (raw 0xd428e6bd)<br>y 0x0 0<br>psr 0xff000082 [ #1 S #24 #25 #26 #27 #28 #29 #30 #31 ]<br>wim 0x0 0<br>tbr 0x0 0<br>pc 0x71094 0x71094!
<x264_sps_write+2228><br>---Type <return> to continue, or
q <return> to quit---<br>npc 0x71098 0x71098 <x264_sps_write+2232><br>fsr 0x0 [ ]<br>csr 0x0 0<br>d0 20.281983359737012 (raw 0x403448300fbc1630)<br>d2 -nan(0xfffffffffffff) (raw 0xffffffffffffffff)<br>d4 -nan(0xfffffffffffff) (raw 0xffffffffffffffff)<br>d6 0.39999997615814209 (raw 0x3fd9999980000000)<br>d8 &nb!
sp; 1 (raw 0x3ff0000000000000)<br>d10 1 (raw 0x3ff0000000000000)<br>d12 1.276291691662309e-17 (raw 0x3c6d6de579694891)<br>d14 4.0970417109975149e-06 (raw 0x3ed12f2a400be110)<br>d16 4.0970500488921436e-06 (raw 0x3ed12f2c8ac60925)<br>d18 0 (raw 0x0000000000000000)<br>d20 -2.8604805813190531e-20 (raw 0xbbe0e2a2d375017f)<br>d22 &nb!
sp; 1.52587890625e-05 &
nbsp; (raw 0x3ef0000000000000)<br>d24 0.00065591277186633509 (raw 0x3f457e31f3bca635)<br>d26 0.26296504550088134 (raw 0x3fd0d46b579ab74b)<br>d28 5.4991993104000338e-14 (raw 0x3d2ef52e721efdc5)<br>d30 0.76826468884902221 (raw 0x3fe8959fd428e6bd)<br><br>But where does it go wrong? Well, it looks like it's here:<br><br>Old value = (uint8_t *) 0xf78f2204 ".00"<br>New value = (uint8_t *) 0xf78f2208 ""<br>x264_sei_version_write (h=<value optimized out>, s=0xa07c8) at ./common/bs.h:125<br>125 s->cur_bits = i_bits;<br>(g!
db)<br>Continuing.<br>Watchpoint 9: s->p<br><br>Old value = (uint8_t *) 0xf78f2208 "\200"<br>New value = (uint8_t *) 0xf78f2209 ""<br>x264_sei_version_write (h=<value optimized out>, s=0xa07c8) at ./common/bs.h:92<br>92 s->i_left = WORD_SIZE*8;<br><br>That is, it looks like it's a result of<br><br>s->p += WORD_SIZE - s->i_left / 8;<br><br>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?<br><br>My SPARC box has gdb and various other tools if anyone needs any more information.<br><br>Thanks.<br>
</font></td></tr>
</table>