Comment 1 for bug 1100200

This feels like a driver misbehaviour to me:

#13 0x00007fbfc71e7982 in GLTexture::bindPixmapToTexture(unsigned long, int, int, int, compiz::opengl::_PixmapSource) () from /usr/lib/compiz/libopengl.so
#14 0x00007fbfc71d1221 in GLWindow::bind() () from /usr/lib/compiz/libopengl.so
#15 0x00007fbfc71d65ba in GLWindow::glDraw(GLMatrix const&, GLWindowPaintAttrib const&, CompRegion const&, unsigned int) () from /usr/lib/compiz/libopengl.so

We never free the window pixmap while a texture is still bound to it. I checked pixmapbinding.cpp and for window pixmaps, we are always guaranteed to have a new valid pixmap for the window before we call GLTexture::List::clear and later call glXBindTexImageEXT on that pixmap.

The only thing I can think of is that the loose binding behaviour in the driver has changed to immediately release pixmap contents upon window destruction for redirected windows whose pixmaps were obtained with XCompositeNameWindowPixmap. I don't think that behaviour would be very smart though, for a number of reasons, so I'll double check with Pierre the next time I get a chance to talk to him.

This is definitely not dupe of bug 1060327 though. The problem there is the potential race condition involving externally managed pixmaps being freed, and then that same handle being used to bind an invalid color buffer to a texture later.

This bug is also about an invalid pixmap being bound to a texture, but in this instance we definitely have a valid reference to the texture, which is why I think the fact that the bind operation fails indicates that something else is causing that reference to be invalid when it shouldn't be.