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