https://bugzilla.novell.com/show_bug.cgi?id=211314 ------- Comment #51 from mhopf@novell.com 2007-01-23 11:41 MST ------- Patch coming. The correct way to remove the reference would be to nuke it when a context is disassociated from a drawable - because after that only the Xserver itself (and not the Mesa subsystem) knows about the context which still has the stray buffer pointer. Unfortunately, if you do that, the server crashes in glxSwapBuffers() - I don't known enough about that code to decide, whether this is a broken implementation, a bug in glxSwapBuffers() (there might be other calls), broken by design, or deliberately chosen this way and actually correct. So the only way is to scan all contexts known for this client for references to this buffer (and the according private structure) when the buffer is actually destroyed. This is done in __glXMesaDrawableDestroy(), which has access to all needed data - all but one. Scanning all contexts only needs the client id (which is known), but the API call FindClientResourcesByType() actually needs a ClientPtr - just to extract the client id! The ClientPtr is only known in glxext.c in a static array __glXClients. I don't know of a different API to get the ClientPtr from, so I exported it. One other possibility would be to add a ClientPtr fetch call to glxext.c, another one to create a new FindClientIDResourcesByType(), another one to create a Client structure with just the id included (ugh!) just for this API call. Making the array extern was the simplest thing to do, but is not necessarily the right solution. There is probably has a better / right possibility to remove all pointers to the buffer (MakeCurrent2?) - but I don't have a better idea ATM. As I consider this a workaround / saveguard for some deeply involved buffer handling bug, I added a lot of ErrorF()s that indicate these failures. If removing these references at this point is the only valid solution, I'd gladly remove these. As the scanning is only invoked on buffer destroys and doesn't do a lot of scanning, performance is not an issue here. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.