Comment 17 for bug 1560909

I tracked this down to the client hanging waiting for mir_connection_release.

Digging further, the root cause is how surface release is handled:

Thread 1 (T1)
 1. calls MirConnection::release_surface
 2. calls mir_connection_release
 3. Makes rpc channel avoid sending any more messages to the server
 4. Waits for server callback (waithandle signal)
 5. ~MirConnection() runs
 5b waits for outstanding rpc calls

Thread 2 (T2)
 1. calls MirConnection::released(SurfaceRelease data)
 2. signals the wait handle
 3. then proceeds to erase BufferStreamIds and SurfaceIds from the surface_map
 4. ^ that causes BufferStream (or streams) to be destroyed which in turn destroy the associated
    BufferDepository and BufferVault
 5. ~BufferVault checks for disconnection. If no disconnection, starts freeing buffers
 5b. RPC calls are made, so pending callbacks are tracked

So dependending on timing, T2.5b could have sneaked an rpc call before T1.3, in which case, there will be a pending callback that will never be satisified, making T1 hang in 5b.

 -