<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv="Content-Type" content="text/html; charset=utf-8"> </HEAD>I don't have access to a SPARC myself. If that data is actually mis-aligned it is quite possible it needs to be fixed so that it is -- I don't think SPARCs, Itaniums or even PowerPCs are capable fixing up misaligned reads from memory as an x86 would (and my understanding is that the fixup does incur a performance hit).<br/><br/>My error was different though -- something about an assertion about 'qscale' failing, and only if I apply gcc optimizations above -O2.<br/><br/>Are you building with gcc or the Sun Studio compiler?<br/><br/>-- Sean<br/><p><hr size=2 width=100% align=center tabindex=-1><b>From</b>: Doug Jackson <ddjack59@gmail.com><br><b>Date</b>: Sun, 9 Aug 2009 15:19:21 -0400<br><b>To</b>: <gseanmcg@gmail.com><br><b>Subject</b>: x264 Solaris<br></font></p>Hi Sean,<br><br>Thanks for the posting about the x264 for Solaris 10 (x86).<br><br>I tried compiling on Solaris 10 SPARC awhile back (several months) and remember having core dump issues when running.<br><br>Here part of the thread:<br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">A recent thread posted a fix for Bus Error on Solaris:<br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote"><pre>It seems the message was only sent to me and a few others, not to the<br><br>ML. Here it is.<br><br>Dark Shikari<br><br>Hello,<br>the bs_init function has two bugs for non aligned p_data pointer.<br><br>I suggest to replace<br> s->i_left = offset ? 8*offset : (WORD_SIZE*8);<br> s->cur_bits = endian_fix( *(intptr_t*)s->p );<br><br>by<br> s->i_left = (WORD_SIZE - offset )*8;<br> s->cur_bits = endian_fix( *(intptr_t*)s->p ) >> s->i_left;<br><br>Mehdi MOSTAFAVI<br><br>inline void bs_init( bs_t *s, void *p_data, int i_data )<br>{<br><br> int offset = ((intptr_t)p_data & (WORD_SIZE-1));<br> s->p = s->p_start = (uint8_t*)p_data - offset;<br> s->p_end = (uint8_t*)p_data + i_data;<br> s->i_left = (WORD_SIZE - offset )*8;<br> s->cur_bits = endian_fix( *(intptr_t*)s->p ) >> s->i_left;<br><br>}<br></pre></blockquote><br><br>I've tried the suggested solution, but still have the error.<br><br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote"> t2000-a# ./<span class="il">x264</span> -B1830 -o foo.264 /football_sif.y4m<br>yuv4mpeg: 352x240@30000/1001fps, 4320:4739<br><span class="il">x264</span> [info]: using SAR=4320/4739<br><span class="il">x264</span> [info]: using cpu capabilities: none!<br><span class="il">x264</span> [info]: profile Main, level 2.1<br> Bus Error (core dumped)<br></blockquote><br>And if I truss:<br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">read(4, " F R A M E\n808080808080".., 8192) = 8192<br> read(4, " g p l N }FDFFFFDC r a t".., 8192) = 8192<br>read(4, " j i t z q g h q x r q v".., 8192) = 8192<br>read(4, " l j q j j m n j j o k i".., 8192) = 8192<br>read(4, " y w o v x y8FA98D i b t".., 8192) = 8192<br> read(4, " % % & # % & $ ( 6 1 8 i".., 8192) = 8192<br>read(4, " Z Z Z X X W P S O O I F".., 8192) = 8192<br>read(4, " n j w l c p p j d V T a".., 8192) = 8192<br>read(4, " } z | r w p r81 y t u81".., 8192) = 8192<br> read(4, " X o o i ` X a m j m d f".., 8192) = 8192<br>read(4, " s p t e j q7F x i c ` i".., 8192) = 8192<br>read(4, " y u } x y } b c d c b a".., 8192) = 8192<br>read(4, " a ` ` ^ ]___ ` a a_".., 8192) = 8192<br> read(4, "8A8C8D898A8D8D8D8D8B8A8A".., 8192) = 8192<br>read(4, "87858B89888988868A8C8E8D".., 8192) = 8192<br>read(4, "8A8D8D8F8F908C8D8C8E8E8F".., 8192) = 8192<br>brk(0x003DEC40) = 0<br> brk(0x003E0C40) = 0<br>brk(0x003E0C40) = 0<br>brk(0x003EAC40) = 0<br>brk(0x003EAC40) = 0<br> brk(0x003F2C40) = 0<br> brk(0x003F2C40) = 0<br>brk(0x0046EC40) = 0<br>brk(0x0046EC40) = 0<br>brk(0x0049AC40) = 0<br> brk(0x0049AC40) = 0<br> brk(0x004A0C40) = 0<br>brk(0x004A0C40) = 0<br>brk(0x004B0C40) = 0<br> Incurred fault #5, FLTACCESS %pc = 0x0009991C<br> siginfo: SIGBUS BUS_ADRALN addr=0x002BB62A<br> Received signal #10, SIGBUS [default]<br> siginfo: SIGBUS BUS_ADRALN addr=0x002BB62A<br></blockquote><br>When looking at bs.h and bs_flush, there is a comment about memory alignment. <br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote"> /* Write the rest of cur_bits to the bitstream; results in a bitstream no longer<br> 32/64-bit aligned. */<br>static inline void bs_flush( bs_t *s )<br>{<br> *(intptr_t*)s->p = endian_fix( s->cur_bits << s->i_left );<br> s->p += WORD_SIZE - s->i_left / 8;<br> s->i_left = WORD_SIZE*8;<br>}<br></blockquote>Could this have something to do with the problem?<br>I'm a novice, so I'm afraid I can only report my experiences.<br><br># uname -a<br>SunOS t2000-a 5.10 Generic_137111-05 sun4v sparc SUNW,Sun-Fire-T200<br><br>Regards,<br><font color="#888888">--Doug</font></blockquote><div><br> Any thoughts as to whether some of the work you have done addresses this? I know memory mgt is less forgiving in SPARC...<br><br>Regards,<br>--Doug<br></div> </html>