Bug 3050

Created attachment 2440 [details]
Tcpdump of the failed session

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

Is this bug still valid?

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.

Latest CVS also has this bug

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

i.e. this is GL_TEXTURE_WIDTH aka GLITZ_GL_TEXTURE_WIDTH

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);
   }

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)

Your testcase produces:
__indirect_glGetTexLevelParameteriv: 0x0de1, 0, 0x1000

Glitz does this:
__indirect_glGetTexLevelParameteriv: 0x84f7, 0, 0x1000

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

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.

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

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

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.

Adding to the monolithic 6.9.1 release tracker (as it's only fixed in cvs head).

(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

Sorry about the phenomenal bug spam, guys.  Adding xorg-team@ to the QA contact so bugs don't get lost in future.

Why is this zombie bug still open? Shouldn't we close it as fixed long ago?

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