Mailinglist Archive: opensuse-bugs (9915 mails)

[bugzilla_noreply@xxxxxxxxxx]

https://bugzilla.novell.com/show_bug.cgi?id=211314





------- Comment #51 from mhopf@xxxxxxxxxx  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.