[Mesa-dev] [Bug 107092] Thread leak when changing context size

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=107092

--- Comment #5 from Roland Scheidegger <sroland at vmware.com> ---
(In reply to Cory Quammen from comment #4)
> Thank you for your quick reply and insight, Roland. Creating and destroying
> glX contexts is a bit of a peculiarity in VTK that we may be able to do away
> with - I'm not sure why VTK does that, so maybe we can work around this
> issue.
> 
> With regards to freeing the screen, I'm afraid I'm nearly completely
> unversed in the Mesa library, so I'm at a loss as to an appropriate fix.
> Could a first step be to free the screen if all surfaces and contexts
> referencing it are free? Is it possible to check that?
I think the problem is precisely that we don't know which surfaces and contexts
reference a screen. Surfaces itself aren't tied to contexts, and nearly all
surfaces are created by pipe screen methods and have to be destroyed by the
equivalent destroy methods, but this isn't true for the surfaces created by X
(and you can and will get things like glXSwapBuffers without any glx context
around any longer).
(At some point we actually did free the screens in xmesa_close_display(), but
this caused crashes, and the commit trading the crashes back for the leaks was:
ommit feb71117aebc0932a96b548b4c402b010a008b2d
Author: George Kyriazis <george.kyriazis at intel.com>
Date:   Fri Mar 4 12:26:00 2016 -0700

    st/xlib: Don't destroy screen on XCloseDisplay()

    screen may still be used by other resources that are not yet freed.
    To correctly fix this there will be a need to account for resources
    differently, but this quick fix is not any worse than the original
    code that leaked screens anyway.

    Reviewed-by: Brian Paul <brianp at vmware.com>
)

I am not entirely sure what actually can still be around if the display is
closed though, my knowledge of the glx code there isn't all that great - but
certainly this is an old issue which should really be addressed.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20180704/e5867917/attachment.html>