On 11/05/17 01:52 PM, Keith Packard wrote: > Delay removing the client from these two queues until all potential > I/O has completed in case we mark the client as ready for reading or > with pending output during the close operation.
Bugzilla: https://bugs.freedesktop.org/100957 > Signed-off-by: Keith Packard <[email protected]> > --- > dix/dispatch.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/dix/dispatch.c b/dix/dispatch.c > index a2df1e0e6..8b371b678 100644 > --- a/dix/dispatch.c > +++ b/dix/dispatch.c > @@ -3414,7 +3414,6 @@ CloseDownClient(ClientPtr client) > if (grabState != GrabNone && grabClient == client) { > UngrabServer(client); > } > - mark_client_not_ready(client); > BITCLEAR(grabWaiters, client->index); > DeleteClientFromAnySelections(client); > ReleaseActiveGrabs(client); > @@ -3443,8 +3442,9 @@ CloseDownClient(ClientPtr client) > if (ClientIsAsleep(client)) > ClientSignal(client); > ProcessWorkQueueZombies(); > - output_pending_clear(client); > CloseDownConnection(client); > + output_pending_clear(client); > + mark_client_not_ready(client); > > /* If the client made it to the Running stage, nClients has > * been incremented on its behalf, so we need to decrement it > I arrived at the same conclusion and am testing a similar patch (only mark_client_not_ready moved down here, and only call mark_client_ready in AbortClient if !client->clientGone). I'm afraid that doesn't explain the ClientReady-after-CloseDownClient case in https://bugs.freedesktop.org/attachment.cgi?id=131278 though, so there might still be another (possibly pre-existing) bug. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
