Re: [Chromium-users] segmentation fault in crserver.

[Brian P. <bri...@tu...>]

If possible, could you try out the Mesa bufferobj.c demo?  It's the 
program I used to test VBOs with the tilesort SPU.

You can get it here: 
http://webcvs.freedesktop.org/mesa/Mesa/progs/tests/bufferobj.c?content-type=text%2Fplain&view=co

-Brian

James Supancic wrote:
> yes, My application uses glGetString(GL_EXTENSIONS); and strstr to tell 
> if the OpenGL implementation supports GL_ARB_vertex_buffer_object. It 
> uses the extension to speed up rendering of geometry heavy scenes.
> 
> I think Chromium should either 1) Not segfualt when the extension is 
> used or 2) Not tell the application that it is supported, though, I 
> prefer the first option myself.
> 
> I am using a basic autodmx config, I changed the basic config a bit to 
> get it to use ssh rather than rsh for starting the crservers, but that 
> is about it.
> 
> Basically, I have a single tilesort SPU and a render SPU on each of the 
> four backends.
> 
> Thank you for your time,
> James Steven Supancic III
> 
> On 7/31/06, *Brian Paul* <bri...@tu... 
> <mailto:bri...@tu...>> wrote:
> 
>     James Supancic wrote:
>      > segmentation fault in crserver.
>      >
>      > I am attempting to run Sauerbraten using Chromium. I have two
>     nVidia and
>      > two ATI render SPUs.
>      > All four render SPUs crash, I was able to get the following stack
>     trace
>      > from the ATI SPUs.
>      > /lib/libpthread.so.0[0xb7ab5e87]
>      > [0xffffe420]
>      >
>     /usr/X11R6/lib/modules/dri/fglrx_dri.so(__glim_R300TCLDrawElements+0xb5b)[0xb735e87b]
>      >
>     /usr/X11R6/lib/modules/dri/fglrx_dri.so(__glim_R300TCLDrawElements+0x129)[0xb735de49]
> 
>      >
>     /usr/X11R6/lib/modules/dri/fglrx_dri.so(__glim_R300TCLDrawElements+0x129)[0xb735de49]
>      >
>     /opt/cr/lib/Linux/libcrserver_crunpacker_copy.so(crUnpackExtendDrawElements+0x7b)[0xb7dfca5f]
>      > /opt/cr/lib/Linux/libcrserver_crunpacker_copy.so[0xb7dfbf8c]
>      >
>     /opt/cr/lib/Linux/libcrserver_crunpacker_copy.so(crUnpack+0x9ed)[0xb7df8693]
>      > /opt/cr/bin/Linux/crserver[0x805657e]
>      > /opt/cr/bin/Linux/crserver[0x805669f]
>      > /opt/cr/bin/Linux/crserver[0x8056789]
>      > /opt/cr/bin/Linux/crserver[0x80567c7]
>      > /opt/cr/bin/Linux/crserver[0x804a537]
>      > /opt/cr/bin/Linux/crserver[0x804a092]
>      > /lib/libc.so.6(__libc_start_main+0xa6)[0xb7be23a6]
>      > /opt/cr/bin/Linux/crserver[0x8049fd1]
>      >
>      > The stacktrace from the nVidia SPUs is much less interesting:
>      > /lib/libpthread.so.0[0xb7afcf37]
>      > [0xffffe420]
>      >
>      > I have noticed that by commenting out
>      > cr_unpackDispatch.DrawElements( mode, count, type, (void *)
>     indices);
>      > in the function crUnpackExtendedDrawElements in the file
>     unpack_arrays.c
>      > and rebuilding Chromium I am able to eliminate the segfaults (the
>      > application still doesn't work, I get some output, but other
>     things are
>      > missing). Using gdb I was able to determine that none of my other
>      > applications cause the crUnpackExtendedDrawElements function to
>     be called.
>      >
>      > Is something wrong with crUnpackExtendedDrawElements?
> 
>     crUnpackExtendedDrawElements() should only be getting used if you're
>     using server-side vertex arrays via the GL_ARB_vertex_buffer_object
>     extension.  Are you?
> 
>     Otherwise, we're probably packing/sending DrawElements() by mistake.
>     What kind of config file are you using?  Tilesort?
> 
>     -Brian
> 
>