(In reply to comment #24) > (In reply to comment #21) > > Looked over this some more with Kristian today. It looks like the root of the > > problem is that the GLX drawable we're destroying in __glXdrawableDestroy has a > > stale corresponding X drawable, which was destroyed in the GLX DestroyWindow > > hook (added by 120286aef59dabdb7c9fa762e08457e5cc8ec3a6).u > > glxDestroyWindow() itself doesn't destroy the DrawableRec, but as I've pointed > out over and over again, the destruction of a window indeed cannot be deferred. > > > That'll make the X drawable go away, but we'll be left with a pDraw pointing > > into freed space, probably crashing when we get to __glXdrawableDestroy for the > > actual GLX drawable in question. > > The purpose of glxDestroyWindow() was to clean up such dangling references. > Apparently it's missing some of them (now). It (120286aef59dabdb7c9fa762e08457e5cc8ec3a6) always missed GLX windows created using glXCreateWindow. Those have a different XID than the X window. For the DestroyWindow hook to work correctly, we have to store the __GLXdrawable as a private on the window, look it up in the hook and then call FreeResource on the glx drawable XID. > > This patch does a lookup on the X drawable ID corresponding to the GLX drawable > > at destruction time, and ignores it if it no longer exists. Kristian put > > together an alternate approach as well but it needs a little work: > > http://people.freedesktop.org/~krh/glx-mess.patch. > > Yeah, when we discussed this kind of issue earlier, Kristian was against using > IDs everywhere, and I think there are good arguments for not doing that. The idea was mostly to avoid the lookup overhead - not that it's a too expensive operation, but since we already looked up the drawable pointer once we might as well hold on to it. The other concern is robustness in case of reused XIDs. > > And per the last comment, DRI2 priv destruction also needs some fixing; I think > > it's now safe to always free the priv and clear the private wherever we call > > DRI2FreeDrawable, since we check everywhere we need to whether the priv still > > exists and so shouldn't crash. > > If you're referring to the last paragraph of comment #19, I'm not sure that'll > do. If there are outstanding swaps referencing the DrawableRec of a window > being destroyed, those swaps will need to be cancelled or whatever is necessary > to clean up the dangling references. Before 711e26466ae04ae93ff4c48d377d83d68a6320e9, the callback mechanism was designed so that the we would hold on to the DRI2 private and pass it back in the DRI2SwapComplete callback. While we can't prevent a window from being destroyed, we can make the DRI2 private ref-counted and keep it alive long enough that any outstanding flips finish. If a window goes away while we have a flip pending, we can NULL the DrawablePtr in the DRI2 private. When the DRI2SwapComplete eventually happens, the DRI2 private is still valid, and will allow us to reliably discover that the window is gone. That mechanism worked well enough I think, but the problem was that we didn't always check to see if the drawable was gone in the callback. Jesse is saying that that's now fixed an we can roll back 711e26466ae04ae93ff4c48d377d83d68a6320e9.