Bug 48535 - Spurious GL_INVALID_OPERATION error generated by glColor()
Summary: Spurious GL_INVALID_OPERATION error generated by glColor()
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/R100 (show other bugs)
Version: 7.10
Hardware: x86-64 (AMD64) Linux (All)
: low minor
Assignee: mesa-dev
QA Contact:
Depends on:
Reported: 2012-04-10 19:56 UTC by Rena Kunisaki
Modified: 2019-09-18 18:40 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

Program that reproduces the issue (152.73 KB, patch)
2012-04-10 19:56 UTC, Rena Kunisaki
Details | Splinter Review
Xorg log (67.75 KB, patch)
2012-04-12 03:32 UTC, Rena Kunisaki
Details | Splinter Review
dmesg (54.20 KB, patch)
2012-04-12 03:33 UTC, Rena Kunisaki
Details | Splinter Review

Description Rena Kunisaki 2012-04-10 19:56:07 UTC
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.
Comment 1 Alex Deucher 2012-04-11 05:43:45 UTC
What card and version of mesa are you using?  Please attach your xorg log and dmesg output.
Comment 2 Vadim Girlin 2012-04-11 16:08:59 UTC
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.
Comment 3 Rena Kunisaki 2012-04-12 03:30:13 UTC
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().
Comment 4 Rena Kunisaki 2012-04-12 03:32:02 UTC
Created attachment 59845 [details] [review]
Xorg log
Comment 5 Rena Kunisaki 2012-04-12 03:33:32 UTC
Created attachment 59846 [details] [review]
Comment 6 Alex Deucher 2012-04-12 06:11:02 UTC
(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.
Comment 7 Ian Romanick 2012-04-13 11:46:51 UTC
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 */ ) {
            /* vertex data for one quad */
            /* assert that error is GL_NO_ERROR */
        /* 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. :)
Comment 8 GitLab Migration User 2019-09-18 18:40:37 UTC
-- 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.