The BadLength looks like a regression from my xserver glx patches a few days ago.  I'll look into this, thanks.

(In reply to comment #1)
> The BadLength looks like a regression from my xserver glx patches a few days
> ago.  I'll look into this, thanks.

Please try the patches in bug#33324 (for xserver).

I tried the two patches (in xserver) and rebuilt.   The problem remains.

(In reply to comment #3)
> I tried the two patches (in xserver) and rebuilt.   The problem remains.

So you're still getting the BadLength?  I tried running sauerbraten but didn't get this crash.

Yes I am (same as initially reported):

init: video: mode
X Error of failed request:  BadLength (poly request too large or internal Xlib length error)
  Major opcode of failed request:  153 (GLX)
  Minor opcode of failed request:  17 (X_GLXVendorPrivateWithReply)
  Serial number of failed request:  19
  Current serial number in output stream:  19

As I mentioned in the initial comment, there were several issues that appeared after I'd upgraded; in particular,  I had to revert some of the changes in xf86-video-ati in order to get X to run at all.  What's weird, is that the logs and console show nothing, and I was left in a "graphics" mode, ultimately requiring me to reboot.   Perhaps the BadLength issue is related to the xf86-video-ati revisions that were kept?

> --- Comment #5 from David Ronis <David.Ronis@McGill.CA> 2011-01-24 07:34:59 PST ---
> Yes I am (same as initially reported):
> 
> init: video: mode
> X Error of failed request:  BadLength (poly request too large or internal Xlib
> length error)
>   Major opcode of failed request:  153 (GLX)
>   Minor opcode of failed request:  17 (X_GLXVendorPrivateWithReply)
>   Serial number of failed request:  19
>   Current serial number in output stream:  19
> 
Just starting the game, then?  Can you run it in gdb, break on
_XError and attach the backtrace?

> As I mentioned in the initial comment, there were several issues that appeared
> after I'd upgraded; in particular,  I had to revert some of the changes in
> xf86-video-ati in order to get X to run at all.  What's weird, is that the logs
> and console show nothing, and I was left in a "graphics" mode, ultimately
> requiring me to reboot.   Perhaps the BadLength issue is related to the
> xf86-video-ati revisions that were kept?
> 
I doubt it, that should just be between mesa and xserver.

I rebuilt sauerbraten with -O2 and -g and ran with a break set at _XError.  Here's what I get:

(gdb) break _XError
Breakpoint 1 at 0xb7a28143
(gdb) run
Starting program: /home/ronis/Project/notar/games/sauerbraten/bin_unix/native_client 
[Thread debugging using libthread_db enabled]
init: sdl
[New Thread 0xb7695b90 (LWP 27845)]
init: net
init: game
init: video: mode

Breakpoint 1, 0xb7a28143 in _XError () from /usr/lib/libX11.so.6
(gdb) thread apply all bt full

Thread 2 (Thread 0xb7695b90 (LWP 27845)):
#0  0xb7ec0a7c in nanosleep () from /lib/libpthread.so.0
No symbol table info available.
#1  0xb7f89b24 in SDL_Delay () from /usr/lib/libSDL-1.2.so.0
No locals.
#2  0x0000011b in ?? ()
No symbol table info available.
#3  0xb7efb000 in ?? ()

[snip (ca 1000 of No symbol table available omitted)]

Thread 1 (Thread 0xb785a6d0 (LWP 27844)):
#0  0xb7a28143 in _XError () from /usr/lib/libX11.so.6
No symbol table info available.
#1  0xb7a25f65 in _XReply () from /usr/lib/libX11.so.6
No symbol table info available.
#2  0x00000001 in ?? ()
No symbol table info available.
#3  0xbfffe500 in ?? ()
No symbol table info available.
#4  0xb7dbb000 in ?? ()
No symbol table info available.
Backtrace stopped: previous frame inner to this frame (corrupt stack?)


Not all that useful.   I suppose that I can rebuild all  or part of Xorg with debugging, but it might be faster to try and back out the patch

> --- Comment #7 from David Ronis <David.Ronis@McGill.CA> 2011-01-24 08:37:58 PST ---
> Not all that useful.   I suppose that I can rebuild all  or part of Xorg with
> debugging, but it might be faster to try and back out the patch
> 
just mesa should be enough.  thanks.

I rebuilt/installed mesa (git origin/master) with debugging support.   Running under gdb with a break set to _XError yields exactly the same backtrace as I reported earlier.   The stack is getting clobbered hard.  Any other suggestions?

Turns out that this problem is more severe than I originally thought.  Not only are GL games affected, but so too are gnome-shell (2.91.5) and mutter (2.91.5). 

I've raised the level of the bug.

I'm willing to try bisection in order to find the problem, but need some guidance as to how to do so.

> --- Comment #10 from David Ronis <David.Ronis@McGill.CA> 2011-01-31 09:55:26 PST ---
> Turns out that this problem is more severe than I originally thought.  Not only
> are GL games affected, but so too are gnome-shell (2.91.5) and mutter (2.91.5). 

please try the patch in bug#33449

I applied the patch from 33449 (as well as the two from 33324 mentioned in comment 2). The build now fails with:

glxcmds.c: In function '__glXDisp_BindTexImageEXT':
glxcmds.c:1702:51: error: macro "REQUEST_AT_LEAST_SIZE" passed 2 arguments, but takes just 1
glxcmds.c:1702:5: error: 'REQUEST_AT_LEAST_SIZE' undeclared (first use in this function)
glxcmds.c:1702:5: note: each undeclared identifier is reported only once for each function it appears in

On Mon, Jan 31, 2011 at 19:13:10 -0800, bugzilla-daemon@freedesktop.org wrote:

> https://bugs.freedesktop.org/show_bug.cgi?id=33351
> 
> --- Comment #12 from David Ronis <David.Ronis@McGill.CA> 2011-01-31 19:13:10 PST ---
> I applied the patch from 33449 (as well as the two from 33324 mentioned in
> comment 2). The build now fails with:
> 
> glxcmds.c: In function '__glXDisp_BindTexImageEXT':

see the later comments in that other bug, was a typo in the patch

I modified the patch as you said in bug #33449 (I'm assuming you simply wanted to replace the 1st  

REQUEST_FIXED_SIZE(xGLXVendorPrivateReq, 8);

by
   if ((sizeof(xGLXVendorPrivateReq) + 12) >> 2 > client->req_len)
      return BadLength;

I rebuild/installed and started X again.   The problem remains.

I had initially not applied the patches in bug 33324.  When I did the problem still remains.

One other thing.  This should all be in the Xserver tree right? :)

I just did a hard reset in xserver xserver and rebuilt/installed.  The problem seems to have been fixed.

Note that I haven't applied any of your patches.