chromium-users

[Chromium-users] segmentation fault in crserver.

[James S. <arr...@gm...>]

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?

Thank you for your time,
James Steven Supancic III

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

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

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

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

[James S. <arr...@gm...>]

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...> 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
>

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
> 
> 

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

[James S. <arr...@gm...>]

I compiled and ran bufferobj.c, the results:

Render SPU 1: Segfault
/lib/libpthread.so.0[0xb7aedf37]
[0xffffe420]
/usr/lib/libGLcore.so.1[0xb757d9c2]

Render SPU 2: Segfault
/usr/lib/opengl/nvidia/lib/libGLcore.so.1[0xb75a7c22]

Render SPU 3: Segfault:
/lib/libpthread.so.0[0xb7a98e87]
[0xffffe420]
/usr/X11R6/lib/modules/dri/fglrx_dri.so(__R300TCLProcessArrayPrimitive+0x183)[0xb733af53]
/usr/X11R6/lib/modules/dri/fglrx_dri.so(__glim_R300TCLDrawArrays+0xff)[0xb734291f]
/opt/cr/lib/Linux/libcrserver_crunpacker_copy.so[0xb7dd8aa7]
/opt/cr/lib/Linux/libcrserver_crunpacker_copy.so(crUnpack+0x218)[0xb7ddaebe]
/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)[0xb7bc53a6]
/opt/cr/bin/Linux/crserver[0x8049fd1]

Render SPU 4: Segfault
/lib/libpthread.so.0[0xb7acee87]
[0xffffe420]
/usr/X11R6/lib/modules/dri/fglrx_dri.so(__R300TCLProcessArrayPrimitive+0x183)[0xb7370f53]
/usr/X11R6/lib/modules/dri/fglrx_dri.so(__glim_R300TCLDrawArrays+0xff)[0xb737891f]
/opt/cr/lib/Linux/libcrserver_crunpacker_copy.so[0xb7e0eaa7]
/opt/cr/lib/Linux/libcrserver_crunpacker_copy.so(crUnpack+0x218)[0xb7e10ebe]
/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)[0xb7bfb3a6]
/opt/cr/bin/Linux/crserver[0x8049fd1]

Are you able to run it without issue? What kind of configuration did you
use?

Thank you for your time,
James Steven Supancic III

On 7/31/06, Brian Paul <bri...@tu...> wrote:
>
> 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
> >
> >
>
>

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

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

James Supancic wrote:
> I compiled and ran bufferobj.c, the results:
> 
> Render SPU 1: Segfault
[...]
> 
> Are you able to run it without issue? What kind of configuration did you 
> use?

It was broken here too.  I've just checked in the fix to the tilesort 
SPU code.  Can you try the CVS code?  Otherwise, I could send you a patch.

-Brian

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

[James S. <arr...@gm...>]

I updated my local copy of the source code (with cvs up) and rebuilt.
bufferobj now runs properly. However, Sauerbraten still causes the crservers
to segfault (with the same error).

What did you have to change to fix bufferobj?

When I run Sauerbraten I get:
Render SPU 1: SegFault
[0xffffe420]

Render SPU 2: SegFault
/lib/libpthread.so.0[0xb7ae8e87]
[0xffffe420]
/usr/X11R6/lib/modules/dri/fglrx_dri.so(__glim_R300TCLDrawElements+0xb5b)[0xb739187b]
/usr/X11R6/lib/modules/dri/fglrx_dri.so(__glim_R300TCLDrawElements+0x129)[0xb7390e49]
/usr/X11R6/lib/modules/dri/fglrx_dri.so(__glim_R300TCLDrawElements+0x129)[0xb7390e49]
/opt/cr/lib/Linux/libcrserver_crunpacker_copy.so(crUnpackExtendDrawElements+0x5c)[0xb7e2f9f0]
/opt/cr/lib/Linux/libcrserver_crunpacker_copy.so[0xb7e2ef3c]
/opt/cr/lib/Linux/libcrserver_crunpacker_copy.so(crUnpack+0x9ed)[0xb7e2b643]
/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)[0xb7c153a6]
/opt/cr/bin/Linux/crserver[0x8049fd1]

Render SPU 3: Segfault
/lib/libpthread.so.0[0xb7adef37]
[0xffffe420]

Render SPU 4: Segfault
/lib/libpthread.so.0[0xb7acfe87]
[0xffffe420]
/usr/X11R6/lib/modules/dri/fglrx_dri.so(__glim_R300TCLDrawElements+0xb5b)[0xb737887b]
/usr/X11R6/lib/modules/dri/fglrx_dri.so(__glim_R300TCLDrawElements+0x129)[0xb7377e49]
/usr/X11R6/lib/modules/dri/fglrx_dri.so(__glim_R300TCLDrawElements+0x129)[0xb7377e49]
/opt/cr/lib/Linux/libcrserver_crunpacker_copy.so(crUnpackExtendDrawElements+0x5c)[0xb7e169f0]
/opt/cr/lib/Linux/libcrserver_crunpacker_copy.so[0xb7e15f3c]
/opt/cr/lib/Linux/libcrserver_crunpacker_copy.so(crUnpack+0x9ed)[0xb7e12643]
/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)[0xb7bfc3a6]
/opt/cr/bin/Linux/crserver[0x8049fd1]

Thank you for your time,
James Steven Supancic III

On 8/1/06, Brian Paul <bri...@tu... > wrote:
>
> James Supancic wrote:
> > I compiled and ran bufferobj.c, the results:
> >
> > Render SPU 1: Segfault
> [...]
> >
> > Are you able to run it without issue? What kind of configuration did you
> > use?
>
> It was broken here too.  I've just checked in the fix to the tilesort
> SPU code.  Can you try the CVS code?  Otherwise, I could send you a patch.
>
> -Brian
>

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

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

James Supancic wrote:
> I updated my local copy of the source code (with cvs up) and rebuilt. 
> bufferobj now runs properly. However, Sauerbraten still causes the 
> crservers to segfault (with the same error).
> 
> What did you have to change to fix bufferobj?

The state differencer was using diff_api.GetString() to determine if 
the GL_ARB_vertex_buffer_object extension was available.  In the 
tilesort SPU, that function pointer was NULL, so the state differencer 
wasn't sending the VBO data to the crservers.

What is Sauerbraten and where can I get it to test?

-Brian

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

[James S. <arr...@gm...>]

Sauerbraten is a free (open source) fps released under the ZLIB license. It
is something of a clone of Quake.

http://sauerbraten.org/ is the project page.

http://sourceforge.net/project/showfiles.php?group_id=102911 is the source
forge download page.
sauerbraten_2006_07_22_normalmap_edition_linux.tar.gz<http://prdownloads.sourceforge.net/sauerbraten/sauerbraten_2006_07_22_normalmap_edition_linux.tar.gz?download>contains
both the source code and pre-compiled binaries.

Thank you for your time,
James Steven Supancic III

On 8/2/06, Brian Paul <bri...@tu...> wrote:
>
> James Supancic wrote:
> > I updated my local copy of the source code (with cvs up) and rebuilt.
> > bufferobj now runs properly. However, Sauerbraten still causes the
> > crservers to segfault (with the same error).
> >
> > What did you have to change to fix bufferobj?
>
> The state differencer was using diff_api.GetString() to determine if
> the GL_ARB_vertex_buffer_object extension was available.  In the
> tilesort SPU, that function pointer was NULL, so the state differencer
> wasn't sending the VBO data to the crservers.
>
> What is Sauerbraten and where can I get it to test?
>
> -Brian
>
>

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

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

Ok, I think I've fixed the vertex array / VBO problem.

We were crashing in glDrawElements() when the vertex data was in a 
server-side VBO but the array element indices were local.

Sauerbraten is a little sub-optimal in that regard.  If you're going 
to put your vertex data into a VBO and you're going to use 
glDrawElements(), the element indices should go in a 
GL_ELEMENT_ARRAY_BUFFER buffer to get best performance.

-Brian

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

[James S. <arr...@gm...>]

I think you may have left the deffintion of crStateUseServerArrayElements
out. I did a cvs checkout to be sure, I tried to build, it failed. so I did
grep -ri crStateUseServerArrayElements ./*
and it returns one line
./spu/tilesort/tilesortspu_client.c:
crStateUseServerArrayElements()) {

ig, you are calling a function without a deffintion. I think...

the tail of the build error is
Compiling tilesortspu_client.c
tilesortspu_client.c: In function `tilesortspu_DrawElements':
tilesortspu_client.c:134: warning: implicit declaration of function
`crStateUseServerArrayElements'
gmake[3]: *** [../../built/tilesortspu/Linux/tilesortspu_client.o] Error 1
gmake[2]: *** [dep] Error 2
gmake[1]: *** [tilesort.subdir] Error 2
make: *** [spu.subdir] Error 2


Thank you for your time,
James Steven Supancic III

On 8/3/06, Brian Paul <bri...@tu...> wrote:
>
>
> Ok, I think I've fixed the vertex array / VBO problem.
>
> We were crashing in glDrawElements() when the vertex data was in a
> server-side VBO but the array element indices were local.
>
> Sauerbraten is a little sub-optimal in that regard.  If you're going
> to put your vertex data into a VBO and you're going to use
> glDrawElements(), the element indices should go in a
> GL_ELEMENT_ARRAY_BUFFER buffer to get best performance.
>
> -Brian
>
>

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

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

James Supancic wrote:
> I think you may have left the deffintion of 
> crStateUseServerArrayElements out. I did a cvs checkout to be sure, I 
> tried to build, it failed. so I did
> grep -ri crStateUseServerArrayElements ./*
> and it returns one line
> ./spu/tilesort/tilesortspu_client.c:                    
> crStateUseServerArrayElements()) {
> 

Sorry, I forgot to check in a couple files.  Try again.

-Brian

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

[James S. <arr...@gm...>]

The application is still very slow, but it no longer causes segmentation
faults =) I am going to toy with some configuration options and see if I can
speed it up a bit that way.

Thank you very much.

Thank you for your time,
James Steven Supancic III

On 8/4/06, Brian Paul <bri...@tu...> wrote:
>
> James Supancic wrote:
> > I think you may have left the deffintion of
> > crStateUseServerArrayElements out. I did a cvs checkout to be sure, I
> > tried to build, it failed. so I did
> > grep -ri crStateUseServerArrayElements ./*
> > and it returns one line
> > ./spu/tilesort/tilesortspu_client.c:
> > crStateUseServerArrayElements()) {
> >
>
> Sorry, I forgot to check in a couple files.  Try again.
>
> -Brian
>

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

[James S. <arr...@gm...>]

While you got Sauerbraten running, you broke tuxracer. I was looking that
the cvs diff to see what you did, and I noticed this
        case GL_UNSIGNED_SHORT:
                {
                        const GLushort *p = (const GLushort *) indices;
                        for (i=0; i<count; i++)
                                crPackExpandArrayElement(p[i], c);
                }
                break;
        case GL_UNSIGNED_INT:
                {
                        const GLushort *p = (const GLushort *) indices;
                        for (i = 0; i < count; i++)
                                crPackExpandArrayElement(p[i], c);
                }
I find that replacing const GLushort *p = (const GLushort *) indices; with
const GLuint *p = (const GLuint *) indices; for case GL_UNSIGNED_INT will
fix tuxracer (which is a mission critical application for many people).

Thank you for your time,
James Steven Supancic III

On 8/4/06, James Supancic <arr...@gm...> wrote:
>
> The application is still very slow, but it no longer causes segmentation
> faults =) I am going to toy with some configuration options and see if I can
> speed it up a bit that way.
>
> Thank you very much.
>
>
> Thank you for your time,
> James Steven Supancic III
>
> On 8/4/06, Brian Paul <bri...@tu...> wrote:
> >
> > James Supancic wrote:
> > > I think you may have left the deffintion of
> > > crStateUseServerArrayElements out. I did a cvs checkout to be sure, I
> > > tried to build, it failed. so I did
> > > grep -ri crStateUseServerArrayElements ./*
> > > and it returns one line
> > > ./spu/tilesort/tilesortspu_client.c:
> > > crStateUseServerArrayElements()) {
> > >
> >
> > Sorry, I forgot to check in a couple files.  Try again.
> >
> > -Brian
> >
>
>

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

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

James Supancic wrote:
> While you got Sauerbraten running, you broke tuxracer. I was looking 
> that the cvs diff to see what you did, and I noticed this
>         case GL_UNSIGNED_SHORT:
>                 {
>                         const GLushort *p = (const GLushort *) indices;
>                         for (i=0; i<count; i++)
>                                 crPackExpandArrayElement(p[i], c);
>                 }
>                 break;
>         case GL_UNSIGNED_INT:
>                 {
>                         const GLushort *p = (const GLushort *) indices;
>                         for (i = 0; i < count; i++)
>                                 crPackExpandArrayElement(p[i], c);
>                 }
> I find that replacing const GLushort *p = (const GLushort *) indices; 
> with const GLuint *p = (const GLuint *) indices; for case 
> GL_UNSIGNED_INT will fix tuxracer (which is a mission critical 
> application for many people).

OK, fixed.

-Brian