Created attachment 59785 [details] [review] Program that reproduces the issue In some unknown circumstance glColor() can raise a GL_INVALID_OPERATION error, which according to the manual should never happen. The attached program reproduces the issue. It's generated from a log of GL calls made by another program, so it's quite long (and some texture-related commands have been stripped out, which I verified does not affect the result). The output I get is: Error 1282 at line 7353 which is consistent with the original program's issue - glColor() suddenly raises this error after making all these GL calls.
What card and version of mesa are you using? Please attach your xorg log and dmesg output.
I guess it's a mesa core problem. Debug build of the mesa also prints the following error message when running the attached test app: "Mesa: User error: GL_INVALID_OPERATION in Inside glBegin/glEnd" It's printed from the ASSERT_OUTSIDE_BEGIN_END_WITH_RETVAL macro in the _mesa_GetError(), called from gl-bug.c:6823. Though it's not inside Begin/End. Probably the error reported later after the glColor call at the line 7353 is just a consequence of the real bug somewhere in the display list handling.
Er, that's not a patch... also I guess I should have actually removed all the glGet() calls instead of just defining them to no-ops. Sorry about that. (The original program was in Lua, which just has gl.Get instead of different functions for different types... rather than try to correct them all, I guessed that they don't contribute to the problem and just redefined them, but forgot to actually delete them.) OpenGL reports the version: 2.1 Mesa 7.10.2. OS is Xubuntu 11.04 x64. Device is Radeon X300SE (PCIE). If I remove the offending glColor() call from the original program, I get the same error a few lines later from glMatrixMode().
Created attachment 59845 [details] [review] Xorg log
Created attachment 59846 [details] [review] dmesg
(In reply to comment #3) > Er, that's not a patch... Yes, but it's easier to view inline in the browser if you set the mimetype to patch.
I did a little poking at the sample case. It appears that the issue is related to display lists. Commenting out all of the glNewList and glEndList calls make the error stop occurring. It also appears that trimming out a bunch of the glBegin/glEnd blocks within certain glNewList/glEndList blocks makes the problem stop occurring. My guess is that we're overflowing some buffer inside the display list compiler code, and bad things happen. One of the side-effects of these bad things is a glEnd gets dropped. We could probably make a reasonable piglit test out of this that just does something like for ( /* a lot */ ) { glNewList(1, GL_COMPILE_AND_EXECUTE); for ( /* a lot */ ) { glBegin(GL_QUADS); /* vertex data for one quad */ glEnd(); glGetError(); /* assert that error is GL_NO_ERROR */ } glEndList(); glGetError(); /* assert that error is GL_NO_ERROR */ } I probably won't have time to dig into this any more, but I think this information should help someone else track it down. :)
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/284.
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.