*** Bug 13211 has been marked as a duplicate of this bug. ***

Looking at the structure, it's been overwritten by other data (function pointers are obviously not function pointers -- one is 1.0f, other is 0).  Running valgrind, there are a bunch of issues with freeing of shader structures, so I suspected the glsl work at first.  However, trying to find a good point to bisect from, I got all the way back to fe20ac2a6b6bb7dee927ee4040debf16e514a858 (sep 25th) with the same basic backtrace from glean.  Much earlier than that and I run into compatibility troubles with the libGL changes from the GLX 1.3 work.

So, when was the last time that glean worked?  I find it hard to believe that you haven't run glean since late september, so I wonder if I'm looking in the wrong place.

Also, I was testing on a 965, so I don't think this is a driver-specific issue (the bug report was put in the 915 category, though I don't see the actual chipset noted in the report).  Running with software GL, I get a backtrace that looks like the shader backtraces that valgrind was complaining about.

Hi, Eric, 
We're continuously running glean, and according to our test result record,
glean is working well(our pass rate is 38/41) for i915 until:
09-22-07 bug #12570 showed up, our pass rate is 7/41
10-05-07 bug #12855 (11-02-07 fixed), our pass rate is 1/41
11-02-07 finally this issue, our pass rate is 2/41

for i965, glean is working(our pass rate is 37/41) well until 10-19-07, pass rate down to 1/41

hope these will help you

I found that when GLX create dricontext and make context current, it will fetch a dri drawable and inserts this drawable into the glx Hash table. (code path: MakeContextCurrent->FetchDRIDrawable-> __glxHashInsert).

When GLX destory dricontext, it will look up glx Hash table and get the dri drawable and destroy it, but it forgets to delete the Hash entry!!!
So when glean finish second round testing on second visual, it will destory the dri drawable, but it get the first dri drawable entry in hash table, which is wrong.

Below is the patch, it will fix this bug. If it is OK, please commit it in.


--- a/src/glx/x11/glxcmds.c
+++ b/src/glx/x11/glxcmds.c
@@ -101,6 +101,7 @@ static void GarbageCollectDRIDrawables(D
                   longer exists in the Xserver */
                (*pdraw->driDrawable.destroyDrawable)(&pdraw->driDrawable);
                XF86DRIDestroyDrawable(dpy, sc->scr, draw);
+                __glxHashDelete(sc->drawHash, draw);
                Xfree(pdraw);
            }
        } while (__glxHashNext(sc->drawHash, &draw, (void *)&pdraw) == 1);

I've checked in the patch from comment #4.  It appears it's not applicable to mesa_7_0_branch.

Thanks for fixing this.  Brian, you're right this in only on mesa master, not the 7.0 branch.

commit 16099c15f5495f22252c6bed655f7f598ebf8001

Mass version move, cvs -> git