Bug 3050

Summary: BadLength error when running glitz apps on top of software Mesa
Product: xorg Reporter: Alexander E. Patrakov <patrakov>
Component: Server/Ext/GLXAssignee: mesa-dev
Status: RESOLVED FIXED QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: high CC: reveman, roland.mainz
Version: 6.8.2   
Hardware: Other   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Tcpdump of the failed session
none
Propoesd test case for this bug.
none
fix bug with texture rectangly proxy target none

Description Alexander E. Patrakov 2005-04-17 04:30:19 UTC
To reproduce with Mesa as of 20050417: 
 
DISPLAY=127.0.0.1:1 LIBGL_ALWAYS_INDIRECT=1 Xglx :2 
 
This creates a window, but it immediately disappears and the following error 
message is printed: 
 
Visual: 0x0 (n) - r/g/b/a: 8/8/8/8  db: 1 
Initialized 800x600 back buffer offscreen area 
X Error of failed request:  BadLength (poly request too large or internal Xlib 
length error) 
  Major opcode of failed request:  146 (GLX) 
  Minor opcode of failed request:  1 (X_GLXRender) 
  Serial number of failed request:  85 
  Current serial number in output stream:  86
Comment 1 Alexander E. Patrakov 2005-04-17 04:32:05 UTC
Created attachment 2440 [details]
Tcpdump of the failed session
Comment 2 Ian Romanick 2005-04-17 12:48:45 UTC
This sounds like it may be the same as something Alexander E. Patrakov reported
in February.  Could you follow the steps in my response to track the problem
down?  I had meant to spend some time and track this down, but, alas, I forgot.

It looked like it may have been a problem in the encoding of
glGetTexLevelParameteriv, but only for certain values of pname.  If this turns
out to be the same place that is generating the error, could you please figure
out what value of pname is causing the error?  Just adding a printf in
__indirect_glGetTexLevelParameteriv should do the trick.

http://marc.theaimsgroup.com/?l=dri-devel&m=110907513724456&w=2
Comment 3 Erik Andren 2006-03-03 05:37:48 UTC
Is this bug still valid?
Comment 4 Alexander E. Patrakov 2006-03-03 20:36:18 UTC
Yes, although I am too lazy to build Xglx now. What bugs me is that the only way
to trigger it is to use glitz.

$ LIBGL_ALWAYS_INDIRECT=1 rendertest_glitz_glx -s 0
X Error of failed request:  BadLength (poly request too large or internal Xlib
length error)
  Major opcode of failed request:  157 (GLX)
  Minor opcode of failed request:  1 (X_GLXRender)
  Serial number of failed request:  76
  Current serial number in output stream:  77

That's with Mesa-6.4.1. Will retest with the latest CVS shortly.
Comment 5 Alexander E. Patrakov 2006-03-03 23:52:51 UTC
Latest CVS also has this bug
Comment 6 Alexander E. Patrakov 2006-03-03 23:57:31 UTC
Printing pname results in the following:

pname is 805F
pname is 805F
pname is 805F
pname is 805F
pname is 805C
pname is 805D
pname is 805E
pname is 805C
pname is 805C
pname is 805D
pname is 805E
pname is 805C
pname is 805D
pname is 805E
pname is 805C
pname is 805C
pname is 805C
pname is 805C
pname is 805C
pname is 805D
pname is 805E
pname is 805F
pname is 805C
pname is 805D
pname is 805E
pname is 805F
pname is 805C
pname is 805D
pname is 805E
pname is 805F
pname is 805C
pname is 805C
pname is 805C
pname is 1000
X Error of failed request:  BadLength (poly request too large or internal Xlib
length error)
  Major opcode of failed request:  157 (GLX)
  Minor opcode of failed request:  1 (X_GLXRender)
  Serial number of failed request:  76
  Current serial number in output stream:  77
Comment 7 Alexander E. Patrakov 2006-03-04 00:16:12 UTC
i.e. this is GL_TEXTURE_WIDTH aka GLITZ_GL_TEXTURE_WIDTH
Comment 8 Ian Romanick 2006-03-04 08:04:56 UTC
Created attachment 4811 [details]
Propoesd test case for this bug.

(In reply to comment #7)
> i.e. this is GL_TEXTURE_WIDTH aka GLITZ_GL_TEXTURE_WIDTH

Based on this, I created a test cased that I *thought* would replicate this
bug.  However, I've tried it on several setup (with indirect rendering,
naturally), and I am unable to reproduce the bug.  Does this test reproduce the
bug on your setup?

If not, could you try logging the texture target and mipmap level parameters
passed to glGetTexLevelParameteriv (in addition to pname)?  Putting something
like this in __indirect_glGetTexLevelParameteriv should do the trick:

   if (pname == GL_TEXTURE_WIDTH) {
      fprintf(stderr, "%s: 0x%04x, %u, 0x%04x\n", __func__, target, level,
	      pname);
   }
Comment 9 Alexander E. Patrakov 2006-03-04 14:42:13 UTC
Your testcase doesn't trigger the bug here either. Have you tried building
glitz-0.5.3 and the "rendertest" program from cairo CVS?

http://cairographics.org/snapshots/glitz-0.5.3.tar.gz
http://webcvs.freedesktop.org/cairo/rendertest/

(the duplicate case label is present in rendertest as of yesterday, trivial to fix)
Comment 10 Alexander E. Patrakov 2006-03-04 14:56:38 UTC
Your testcase produces:
__indirect_glGetTexLevelParameteriv: 0x0de1, 0, 0x1000

Glitz does this:
__indirect_glGetTexLevelParameteriv: 0x84f7, 0, 0x1000
Comment 11 Ian Romanick 2006-03-04 16:00:56 UTC
(In reply to comment #10)
> Your testcase produces:
> __indirect_glGetTexLevelParameteriv: 0x0de1, 0, 0x1000
> 
> Glitz does this:
> __indirect_glGetTexLevelParameteriv: 0x84f7, 0, 0x1000

Ah-ha!  I changed the test case to use GL_PROXY_TEXTURE_RECTANGLE_ARB and now
the test case can reproduce the bug.  In addition, the test case is no comitted
to Mesa CVS as progs/tests/bug_3050.c.

I'm not sure why the texture target would make any difference, but I'll look
into it.
Comment 12 Roland Scheidegger 2006-03-06 01:23:26 UTC
Created attachment 4831 [details] [review]
fix bug with texture rectangly proxy target

It looks like the texture rectangle proxy target is missing in
__glXTexImage2DReqSize as a special case (proxies are special case because
image size is always 0). This seems enough to fix this bug, though not knowing
anything about glx I'd rather have someone else take a look too...
btw the test program is a bit bogus, glBindTexture won't succeed with proxy
textures.
Comment 13 Ian Romanick 2006-03-07 03:38:22 UTC
(In reply to comment #12)
> Created an attachment (id=4831) [edit]
> fix bug with texture rectangly proxy target
> 
> It looks like the texture rectangle proxy target is missing in
> __glXTexImage2DReqSize as a special case (proxies are special case because
> image size is always 0). This seems enough to fix this bug, though not knowing
> anything about glx I'd rather have someone else take a look too...

I was able to reproduce this bug on X.org 7.0.0, which does not contain the code
that your patch modifies.  What version is that?  6.8.2?  Older?

The code in X.org handles all the proxy targets.  The error seems to be in the
protocol for glGetTexLevelParameter[if]v, which doesn't go any where near
__glXImageSize.

> btw the test program is a bit bogus, glBindTexture won't succeed with proxy
> textures.

Yeah, I noticed that one time when I accidentally ran it with direct rendering.
 I just committed a fix to Mesa CVS.
Comment 14 Roland Scheidegger 2006-03-07 04:36:58 UTC
(In reply to comment #13)
> I was able to reproduce this bug on X.org 7.0.0, which does not contain the code
> that your patch modifies.  What version is that?  6.8.2?  Older?
Ah sorry on that box it's still 6.9. In any case the code still is in xorg 7.0
as far as I can see (xserver module xserver/GL/glx)

> The code in X.org handles all the proxy targets.  The error seems to be in the
> protocol for glGetTexLevelParameter[if]v, which doesn't go any where near
> __glXImageSize.
No, the crash happens after glTexImage2D, though it looks like the error is
reported only later (due to asynchronous protocol I'd guess).
Comment 15 Ian Romanick 2006-03-08 05:00:11 UTC
Ah...that seems right.  I just re-tested it to a remote system with X.org CVS,
and the bug does not appear.  I conclude that it was fixed by my changes to the
6.9 / 7.0 tree, then.

I'm going to leave this bug open, but I'll change the product / version to xorg
6.8.2.
Comment 16 Roland Scheidegger 2006-03-08 07:51:40 UTC
Adding to the monolithic 6.9.1 release tracker (as it's only fixed in cvs head).
Comment 17 Peter Gracar 2006-03-09 23:36:07 UTC
(In reply to comment #15)
> Ah...that seems right.  I just re-tested it to a remote system with X.org CVS,
> and the bug does not appear.  I conclude that it was fixed by my changes to the
> 6.9 / 7.0 tree, then.
> 
> I'm going to leave this bug open, but I'll change the product / version to xorg
> 6.8.2.

Using xorg 7.0 and getting this issue:

root@Damage-Inc:/home/peter# Xgl :1 -ac -accel glx:pbuffer -accel xv:pbuffer
X Error of failed request:  BadLength (poly request too large or internal Xlib l
ength error)
  Major opcode of failed request:  143 (GLX)
  Minor opcode of failed request:  1 (X_GLXRender)
  Serial number of failed request:  94
  Current serial number in output stream:  95
Comment 18 Daniel Stone 2007-02-27 01:26:22 UTC
Sorry about the phenomenal bug spam, guys.  Adding xorg-team@ to the QA contact so bugs don't get lost in future.
Comment 19 Alexander E. Patrakov 2010-06-20 05:35:00 UTC
Why is this zombie bug still open? Shouldn't we close it as fixed long ago?
Comment 20 Jesse Adkins 2010-11-28 22:37:23 UTC
(In reply to comment #19)
> Why is this zombie bug still open? Shouldn't we close it as fixed long ago?

Assuming that this has been fixed, since the only complaint after fixes were mentioned was from someone using xgl which no longer exists.

If I'm wrong about this, feel free to reopen this bug.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.