Please do not reply to this email: if you want to comment on the bug, go to    
       
the URL shown below and enter yourcomments there.     
   
https://bugs.freedesktop.org/show_bug.cgi?id=7205          
     




------- Additional Comments From [EMAIL PROTECTED]  2007-01-23 11:49 -------
Created an attachment (id=8488)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=8488&action=view)
Clean stray framebuffer and glxPriv pointers in reused contexts

Programs apparently crash if a context is reused for a window that changed in
the meantime. Crashes apparently only ocure for software rendering.

The basic problem is that a buffer is freed, when the according window is
closed, but the old context (which is no longer referenced in _glapi_Context
or in the according glxPriv structures) still has a reference to this buffer,
and is reactivated later. As the buffer points to a freed memory location, it
is no longer recognized as an old buffer (because buffer->Name - by accident -
contains 0x00cccccc) and not replaced.


About this patch:

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 and glxPriv pointers.
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 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.


This patch is against xserver git (applies to older versions as well).          
     
     
--           
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email         
     
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Reply via email to