Mir

mir_connection_release does not free associated surfaces

Bug #1194534 reported by Kevin DuBois
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mir
Fix Released
Medium
Alan Griffiths
mir (Ubuntu)
Fix Released
Medium
Unassigned

Bug Description

mir_surface_release() is needed before mir_connection_release() in order to clean up resources on the client side. This wishlist bug could be resolved by either 1) documenting this a bit better or 2) making it so that resources associated with the connection are cleaned up on mir_connection_release

Tags: clientapi
summary: - mir_surface_release needed before mir_connection_release
+ mir_connection_release does not free associated surfaces
Changed in mir:
importance: Wishlist → Medium
tags: added: clientapi
Revision history for this message
Alan Griffiths (alan-griffiths) wrote :

My preference is for the client code being responsible for cleaning up any resources it allocates. (And not having mir_connection_release() do it implicitly - although it might make sense to have the latter block while surfaces are held.)

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Yes, the client is responsible. But MirSurface is really a subordinate object to MirConnection. If you destroy the MirConnection then I think it's just good API design to automatically destroy any remaining surfaces owned by that connection.

Revision history for this message
Alan Griffiths (alan-griffiths) wrote :

I'm not such a fan of things happening "by magic".

If a client hasn't released the surfaces when it disconnects it is buggy (either because it always leaks, or because there is a race condition and the release is yet to happen).

We should be making it easy for developers of clients to detect bugs - not concealing the effects of their bugs.

If we do as you suggest then leaky clients appear to work, and racy ones intermittently hit undefined behaviour by releasing tie surface for a second time.

If we were to block pending all surfaces closed, then racy clients appear to work and leaky ones hang.

If we "assert" that all surfaces have been closed, then both types of bug are detected early. I'm tempted.

Changed in mir:
status: New → Triaged
Revision history for this message
Alexandros Frantzis (afrantzis) wrote :

Fixed in mir/devel r1700, released in 0.3.0

Changed in mir:
assignee: nobody → Alan Griffiths (alan-griffiths)
status: Triaged → Fix Released
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Branch 0.3 happened on revision 1691 so the fix actually first landed in series 0.4 but it appears to have been backported to the 0.3 series immediately before tag 0.3.0 so close enough...

Changed in mir:
milestone: none → 0.3.0
Changed in mir (Ubuntu):
status: New → Fix Released
importance: Undecided → Medium
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.