** Description changed:

+ [Impact]
+ 
+ There is a race in libx11 causing applications to randomly abort. It's
+ not trivial to reproduce, but there are enough duplicates that this
+ deserves an SRU to bionic & focal.
+ 
+ [Fix]
+ 
+ Backport a commit from upstream:
+ 
+ From dbb55e1a5e82870466b095097d9e46046680ec25 Mon Sep 17 00:00:00 2001
+ From: Frediano Ziglio <fzig...@redhat.com>
+ Date: Wed, 29 Jan 2020 09:06:54 +0000
+ Subject: [PATCH] Fix poll_for_response race condition
+ 
+ In poll_for_response is it possible that event replies are skipped
+ and a more up to date message reply is returned.
+ This will cause next poll_for_event call to fail aborting the program.
+ 
+ This was proved using some slow ssh tunnel or using some program
+ to slow down server replies (I used a combination of xtrace and strace).
+ 
+ How the race happens:
+ - program enters into poll_for_response;
+ - poll_for_event is called but the server didn't still send the reply;
+ - pending_requests is not NULL because we send a request (see call
+   to  append_pending_request in _XSend);
+ - xcb_poll_for_reply64 is called from poll_for_response;
+ - xcb_poll_for_reply64 will read from server, at this point
+   server reply with an event (say sequence N) and the reply to our
+   last request (say sequence N+1);
+ - xcb_poll_for_reply64 returns the reply for the request we asked;
+ - last_request_read is set to N+1 sequence in poll_for_response;
+ - poll_for_response returns the response to the request;
+ - poll_for_event is called (for instance from another poll_for_response);
+ - event with sequence N is retrieved;
+ - the N sequence is widen, however, as the "new" number computed from
+   last_request_read is less than N the number is widened to N + 2^32
+   (assuming last_request_read is still contained in 32 bit);
+ - poll_for_event enters the nested if statement as req is NULL;
+ - we compare the widen N (which now does not fit into 32 bit) with
+   request (which fits into 32 bit) hitting the throw_thread_fail_assert.
+ 
+ To avoid the race condition and to avoid the sequence to go back
+ I check again for new events after getting the response and
+ return this last event if present saving the reply to return it
+ later.
+ 
+ To test the race and the fix it's helpful to add a delay (I used a
+ "usleep(5000)") before calling xcb_poll_for_reply64.
+ 
+ Original patch written by Frediano Ziglio, see
+ https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/34
+ 
+ Reworked primarily for readability by Peter Hutterer, see
+ https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/53
+ 
+ Signed-off-by: Peter Hutterer <peter.hutte...@who-t.net>
+ 
+ bionic needs another commit so that the real fix applies.
+ 
+ [Test case]
+ 
+ It's a race condition, the SRU sponsor (tjaalton) does not have a test
+ case for this, but the bug subscribers seem to.
+ 
+ 
+ [Where things could go wrong]
+ 
+ In theory there might be a case where a race still happens, but since
+ this has been upstream for a year now with no follow-up commits, it's
+ safe to assume that there are no regressions.
+ 
+ 
+ --
+ 
  STEPS TO REPRODUCE
  ==================
  The bug seems to occur when clicking on a file or folder. It is random and 
difficult to provide clear steps to reproduce. It is, however, a common 
situation.
  
  EXPECTED RESULTS
  ================
  pcmanfm works without problem.
  
  ACTUAL RESULTS
  ==============
  All pcmanfm windows become unresponsive, though background processes (e.g. 
copying) may continue without problem. with the same error message in 
~/.cache/lxsession/LXDE/run.log:
  
  [xcb] Unknown sequence number while processing queue
  [xcb] Most likely this is a multi-threaded client and XInitThreads has not 
been called
  [xcb] Aborting, sorry about that.
  pcmanfm: xcb_io.c:259: poll_for_event: Assertion 
`!xcb_xlib_threads_sequence_lost' failed.
  ** Message: 19:58:49.267: app.vala:130: pcmanfm exit with this type of exit: 6
  ** Message: 19:58:49.268: app.vala:148: Exit not normal, try to reload
  
  (note the timestamp on the message will vary)
  
  AFFECTED VERSIONS
  =================
  1.2.5-3ubuntu1
  NOT 1.2.4-1ubuntu0.1
  
  UPSTREAM BUG
  ============
  https://sourceforge.net/p/pcmanfm/bugs/1089/
  
  ADDITIONAL NOTES
  ================
  Other GTK2 file managers (e.g. Thunar) and applications (e.g. GIMP, Leafpad) 
seem to have the same problems. This is probably at least rooted in a GTK2 bug:
  https://bugs.launchpad.net/ubuntu/+source/gtk+2.0/+bug/1808710
  
  To further assert this, note that there is a SpaceFM file manager that
  is available in GTK2 and GTK3. The GTK2 version displays the behavior.
  The GTK3 version does not. Same with LibreOffice.

-- 
You received this bug notification because you are a member of Ubuntu-X,
which is subscribed to libx11 in Ubuntu.
https://bugs.launchpad.net/bugs/1782984

Title:
  Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple
  applications

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libx11/+bug/1782984/+subscriptions


_______________________________________________
Mailing list: https://launchpad.net/~ubuntu-x-swat
Post to     : ubuntu-x-swat@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-x-swat
More help   : https://help.launchpad.net/ListHelp

Reply via email to