[Touch-packages] [Bug 1782984] Re: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications
Please ensure your application is calling XInitThreads before commenting here. If it's not calling XInitThreads then that's probably an application bug. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libx11 in Ubuntu. https://bugs.launchpad.net/bugs/1782984 Title: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications Status in libx11 package in Ubuntu: Fix Released Status in libx11 source package in Bionic: Fix Committed Status in libx11 source package in Focal: Fix Committed Status in libx11 source package in Groovy: Won't Fix Bug description: [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 Date: Wed, 29 Jan 2020 09:06:54 + 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 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
[Touch-packages] [Bug 1782984] Re: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications
The same error when executing UIO tests in eclipse under docker environment [xcb] Unknown sequence number while processing reply [xcb] Most likely this is a multi-threaded client and XInitThreads has not been called [xcb] Aborting, sorry about that. java: ../../src/xcb_io.c:702: _XReply: Assertion `!xcb_xlib_threads_sequence_lost' failed. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libx11 in Ubuntu. https://bugs.launchpad.net/bugs/1782984 Title: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications Status in libx11 package in Ubuntu: Fix Released Status in libx11 source package in Bionic: Fix Committed Status in libx11 source package in Focal: Fix Committed Status in libx11 source package in Groovy: Won't Fix Bug description: [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 Date: Wed, 29 Jan 2020 09:06:54 + 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 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
[Touch-packages] [Bug 1782984] Re: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications
I still see this issue even after the suggested change [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. java: ../../src/xcb_io.c:260: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed. [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. java: ../../src/xcb_io.c:260: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed. in my docker file I have RUN echo 'deb http://archive.ubuntu.com/ubuntu/ focal-proposed main restricted' >> /etc/apt/sources.list && \ apt-get update -q -y && \ apt-get install -y --fix-missing --no-install-recommends \ libx11-6 && \ apt-get purge -y pm-utils xscreensaver* && \ apt-get autoremove -y && \ apt-get clean -y && \ rm -rf /var/lib/apt/lists/* -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libx11 in Ubuntu. https://bugs.launchpad.net/bugs/1782984 Title: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications Status in libx11 package in Ubuntu: Fix Released Status in libx11 source package in Bionic: Fix Committed Status in libx11 source package in Focal: Fix Committed Status in libx11 source package in Groovy: Won't Fix Bug description: [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 Date: Wed, 29 Jan 2020 09:06:54 + 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 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
[Touch-packages] [Bug 1782984] Re: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications
I am not installing all updates my docker file is as follows RUN echo 'deb http://archive.ubuntu.com/ubuntu/ focal-proposed main restricted' >> /etc/apt/sources.list && \ apt-get update -q -y && \ apt-get install -y --fix-missing --no-install-recommends \ libx11-6 \ //more packages apt-get purge -y pm-utils xscreensaver* && \ apt-get autoremove -y && \ apt-get clean -y && \ rm -rf /var/lib/apt/lists/* -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libx11 in Ubuntu. https://bugs.launchpad.net/bugs/1782984 Title: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications Status in libx11 package in Ubuntu: Fix Released Status in libx11 source package in Bionic: Fix Committed Status in libx11 source package in Focal: Fix Committed Status in libx11 source package in Groovy: Won't Fix Bug description: [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 Date: Wed, 29 Jan 2020 09:06:54 + 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 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 =
[Touch-packages] [Bug 1782984] Re: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications
That'll install all updates from proposed? Don't do that. Just use a clean image and then install the required updates as mentioned in #106 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libx11 in Ubuntu. https://bugs.launchpad.net/bugs/1782984 Title: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications Status in libx11 package in Ubuntu: Fix Released Status in libx11 source package in Bionic: Fix Committed Status in libx11 source package in Focal: Fix Committed Status in libx11 source package in Groovy: Won't Fix Bug description: [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 Date: Wed, 29 Jan 2020 09:06:54 + 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 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
[Touch-packages] [Bug 1782984] Re: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications
My DockerFile looks like RUN echo 'deb http://archive.ubuntu.com/ubuntu/ focal-proposed main restricted' >> /etc/apt/sources.list && \ apt-get update -q -y && \ apt-get install -y --fix-missing --no-install-recommends \ -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libx11 in Ubuntu. https://bugs.launchpad.net/bugs/1782984 Title: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications Status in libx11 package in Ubuntu: Fix Released Status in libx11 source package in Bionic: Fix Committed Status in libx11 source package in Focal: Fix Committed Status in libx11 source package in Groovy: Won't Fix Bug description: [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 Date: Wed, 29 Jan 2020 09:06:54 + 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 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
[Touch-packages] [Bug 1782984] Re: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications
So I added the lines from comment 132 in my docker file and I now I am not able to build my docker image I get the following error 10:23:39 xg++: fatal error: Killed signal terminated program cc1plus 10:23:39 compilation terminated. 10:23:39 make[3]: *** [Makefile:1117: insn-emit.o] Error 1 10:23:39 make[3]: *** Waiting for unfinished jobs 10:25:45 /bin/bash ../../gcc/gcc/../move-if-change tmp-attrtab.c insn-attrtab.c 10:25:45 /bin/bash ../../gcc/gcc/../move-if-change tmp-dfatab.c insn-dfatab.c 10:25:45 /bin/bash ../../gcc/gcc/../move-if-change tmp-latencytab.c insn-latencytab.c 10:25:45 echo timestamp > s-attrtab 10:26:32 In file included from ../../gcc/gcc/coretypes.h:452, 10:26:32 from ../../gcc/gcc/expmed.c:26: 10:26:32 ../../gcc/gcc/machmode.h: In function 'rtx_def* emit_store_flag_1(rtx, rtx_code, rtx, rtx, machine_mode, int, int, machine_mode)': 10:26:32 ../../gcc/gcc/machmode.h:546:42: warning: 'int_mode' may be used uninitialized in this function [-Wmaybe-uninitialized] 10:26:32546 |? mode_size_inline (mode) : mode_size[mode]); 10:26:32| ^~~~ 10:26:32 ../../gcc/gcc/expmed.c:5625:19: note: 'int_mode' was declared here 10:26:32 5625 | scalar_int_mode int_mode; 10:26:32| ^~~~ 10:26:54 rm gcc.pod 10:26:54 make[3]: Leaving directory '/tmp/build/gcc' 10:26:54 make[2]: *** [Makefile:4834: all-stage3-gcc] Error 2 10:26:54 make[2]: Leaving directory '/tmp/build' 10:26:54 make[1]: *** [Makefile:27340: stage3-bubble] Error 2 10:26:54 make[1]: Leaving directory '/tmp/build' 10:26:54 make: *** [Makefile:1007: all] Error 2 10:26:54 error building image: error building stage: failed to execute command: waiting for process to exit: exit status 2 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libx11 in Ubuntu. https://bugs.launchpad.net/bugs/1782984 Title: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications Status in libx11 package in Ubuntu: Fix Released Status in libx11 source package in Bionic: Fix Committed Status in libx11 source package in Focal: Fix Committed Status in libx11 source package in Groovy: Won't Fix Bug description: [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 Date: Wed, 29 Jan 2020 09:06:54 + 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 bionic needs another commit so that the real fix applies. [Test case] It's
[Touch-packages] [Bug 1782984] Re: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications
or do as advised in comment #106 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libx11 in Ubuntu. https://bugs.launchpad.net/bugs/1782984 Title: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications Status in libx11 package in Ubuntu: Fix Released Status in libx11 source package in Bionic: Fix Committed Status in libx11 source package in Focal: Fix Committed Status in libx11 source package in Groovy: Won't Fix Bug description: [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 Date: Wed, 29 Jan 2020 09:06:54 + 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 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
[Touch-packages] [Bug 1782984] Re: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications
echo 'deb http://archive.ubuntu.com/ubuntu/ focal-proposed main restricted' >> /etc/apt/sources.list apt update apt install libx11-6 verify with 'apt-cache policy libx11-6' that you have the correct version (from proposed), and run your tests. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libx11 in Ubuntu. https://bugs.launchpad.net/bugs/1782984 Title: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications Status in libx11 package in Ubuntu: Fix Released Status in libx11 source package in Bionic: Fix Committed Status in libx11 source package in Focal: Fix Committed Status in libx11 source package in Groovy: Won't Fix Bug description: [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 Date: Wed, 29 Jan 2020 09:06:54 + 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 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)
[Touch-packages] [Bug 1782984] Re: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications
I am using docker file to get ubuntu 20.04 and install packages. How can I enable focal-proposed insider docker? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libx11 in Ubuntu. https://bugs.launchpad.net/bugs/1782984 Title: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications Status in libx11 package in Ubuntu: Fix Released Status in libx11 source package in Bionic: Fix Committed Status in libx11 source package in Focal: Fix Committed Status in libx11 source package in Groovy: Won't Fix Bug description: [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 Date: Wed, 29 Jan 2020 09:06:54 + 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 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:
[Touch-packages] [Bug 1782984] Re: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications
did you enable focal-proposed? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libx11 in Ubuntu. https://bugs.launchpad.net/bugs/1782984 Title: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications Status in libx11 package in Ubuntu: Fix Released Status in libx11 source package in Bionic: Fix Committed Status in libx11 source package in Focal: Fix Committed Status in libx11 source package in Groovy: Won't Fix Bug description: [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 Date: Wed, 29 Jan 2020 09:06:54 + 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 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
[Touch-packages] [Bug 1782984] Re: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications
I have updated my docker image to use ubuntu 20.04 and I still see this error with eclipse when running UI SWTBot tests. I get the following error [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. java: ../../src/xcb_io.c:260: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libx11 in Ubuntu. https://bugs.launchpad.net/bugs/1782984 Title: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications Status in libx11 package in Ubuntu: Fix Released Status in libx11 source package in Bionic: Fix Committed Status in libx11 source package in Focal: Fix Committed Status in libx11 source package in Groovy: Won't Fix Bug description: [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 Date: Wed, 29 Jan 2020 09:06:54 + 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 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
[Touch-packages] [Bug 1782984] Re: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications
Interactively, after you have found the 'Ubuntu on Wayland' option on the login screen once, it will then become the default in future* * Unless 'Ubuntu on Wayland' crashes in which case the option gets disabled and it reverts to 'Ubuntu' which is a Xorg session. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libx11 in Ubuntu. https://bugs.launchpad.net/bugs/1782984 Title: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications Status in libx11 package in Ubuntu: Fix Released Status in libx11 source package in Bionic: Fix Committed Status in libx11 source package in Focal: Fix Committed Status in libx11 source package in Groovy: Won't Fix Bug description: [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 Date: Wed, 29 Jan 2020 09:06:54 + 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 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
[Touch-packages] [Bug 1782984] Re: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications
I am updating my ubuntu docker file to use ubuntu 20.04 will it resolve this issue ? any idea how can I achieve logging into ubuntu on wayland in docker environment? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libx11 in Ubuntu. https://bugs.launchpad.net/bugs/1782984 Title: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications Status in libx11 package in Ubuntu: Fix Released Status in libx11 source package in Bionic: Fix Committed Status in libx11 source package in Focal: Fix Committed Status in libx11 source package in Groovy: Won't Fix Bug description: [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 Date: Wed, 29 Jan 2020 09:06:54 + 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 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
[Touch-packages] [Bug 1782984] Re: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications
Logging into 'Ubuntu on Wayland' is probably a good workaround because it should avoid this problem completely. Although we would recommend using Ubuntu 20.04 over 18.04. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libx11 in Ubuntu. https://bugs.launchpad.net/bugs/1782984 Title: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications Status in libx11 package in Ubuntu: Fix Released Status in libx11 source package in Bionic: Fix Committed Status in libx11 source package in Focal: Fix Committed Status in libx11 source package in Groovy: Won't Fix Bug description: [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 Date: Wed, 29 Jan 2020 09:06:54 + 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 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
[Touch-packages] [Bug 1782984] Re: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications
I am using ubuntu 18.04 in docker environment and running swtbot tests using eclipse. I get the same error. I updated my docker file to install libx11-6 but the problem still exists. The tests execution is aborted with the following error message [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. java: ../../src/xcb_io.c:259: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed. Is there any fix/workaround available for this bug? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libx11 in Ubuntu. https://bugs.launchpad.net/bugs/1782984 Title: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications Status in libx11 package in Ubuntu: Fix Released Status in libx11 source package in Bionic: Fix Committed Status in libx11 source package in Focal: Fix Committed Status in libx11 source package in Groovy: Won't Fix Bug description: [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 Date: Wed, 29 Jan 2020 09:06:54 + 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 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:
[Touch-packages] [Bug 1782984] Re: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications
Ok. So it seems that the bug *exists* in Focal, so now we just need to verify that the bug is *fixed* by the proposed package. @angie78 - as you seem to suffer from the bug, can you try to verify that the proposed packages (from https://bugs.launchpad.net/ubuntu/+source/libx11/+bug/1782984/comments/106 ) fix the bug? Once we've got verification that the bug is fixed, we can release the packages into -updates and everyone can benefit! Anyone else is also welcome to verify! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libx11 in Ubuntu. https://bugs.launchpad.net/bugs/1782984 Title: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications Status in libx11 package in Ubuntu: Fix Released Status in libx11 source package in Bionic: Fix Committed Status in libx11 source package in Focal: Fix Committed Status in libx11 source package in Groovy: Won't Fix Bug description: [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 Date: Wed, 29 Jan 2020 09:06:54 + 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 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)
[Touch-packages] [Bug 1782984] Re: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications
Any update on this bug and the status of focal? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libx11 in Ubuntu. https://bugs.launchpad.net/bugs/1782984 Title: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications Status in libx11 package in Ubuntu: Fix Released Status in libx11 source package in Bionic: Fix Committed Status in libx11 source package in Focal: Fix Committed Status in libx11 source package in Groovy: Won't Fix Bug description: [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 Date: Wed, 29 Jan 2020 09:06:54 + 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 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
[Touch-packages] [Bug 1782984] Re: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications
Has anyone tried PCManFM or Inkscape on focal? It seems that this update doesn't fix GNOME Shell on focal, but *maybe* that's because Shell is hitting a different bug? If this can be verified to fix PCManFM, Inkscape, or something on focal we can release it and open a new bug for GNOME Shell on Focal. If this *doesn't* fix something on focal, we need to work out why - maybe it needs more changes backported, like bionic did? If FCManFM & Inkscape don't hang on focal *without* this update then I think we can release the bionic update and close the focal task. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libx11 in Ubuntu. https://bugs.launchpad.net/bugs/1782984 Title: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications Status in libx11 package in Ubuntu: Fix Released Status in libx11 source package in Bionic: Fix Committed Status in libx11 source package in Focal: Fix Committed Status in libx11 source package in Groovy: Won't Fix Bug description: [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 Date: Wed, 29 Jan 2020 09:06:54 + 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 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:
[Touch-packages] [Bug 1782984] Re: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications
** Tags removed: lubuntu -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libx11 in Ubuntu. https://bugs.launchpad.net/bugs/1782984 Title: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications Status in libx11 package in Ubuntu: Fix Released Status in libx11 source package in Bionic: Fix Committed Status in libx11 source package in Focal: Fix Committed Status in libx11 source package in Groovy: Won't Fix Bug description: [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 Date: Wed, 29 Jan 2020 09:06:54 + 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 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
[Touch-packages] [Bug 1782984] Re: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications
comment #113 still holds, focal needs to be verified first -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libx11 in Ubuntu. https://bugs.launchpad.net/bugs/1782984 Title: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications Status in libx11 package in Ubuntu: Fix Released Status in libx11 source package in Bionic: Fix Committed Status in libx11 source package in Focal: Fix Committed Status in libx11 source package in Groovy: Won't Fix Bug description: [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 Date: Wed, 29 Jan 2020 09:06:54 + 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 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
[Touch-packages] [Bug 1782984] Re: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications
> N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days I've seen that the `verification-done-bionic` tag has been added on September 4th, which was 19 days ago. Could someone please tell when this fix will be available via `-updates` for bionic? It's a top-crash in our CI, and it would be great to see it fixed. Thanks a lot! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libx11 in Ubuntu. https://bugs.launchpad.net/bugs/1782984 Title: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications Status in libx11 package in Ubuntu: Fix Released Status in libx11 source package in Bionic: Fix Committed Status in libx11 source package in Focal: Fix Committed Status in libx11 source package in Groovy: Won't Fix Bug description: [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 Date: Wed, 29 Jan 2020 09:06:54 + 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 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
[Touch-packages] [Bug 1782984] Re: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications
It looks like I was wrong, and the crash is still occurring with libx11-6 2:1.7.0-2ubuntu0.1 in hirsute, for example: https://errors.ubuntu.com/oops/91f6b2d4-1353-11ec-a828-fa163e102db1 The fact that the crash frequency dropped way off after 20.04 could just be explained by: * Most people stick to LTS and so haven't upgraded yet; and * Those who are using 21.04 are more likely to be using Wayland (the new default) which would avoid the bug. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libx11 in Ubuntu. https://bugs.launchpad.net/bugs/1782984 Title: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications Status in libx11 package in Ubuntu: Fix Released Status in libx11 source package in Bionic: Fix Committed Status in libx11 source package in Focal: Fix Committed Status in libx11 source package in Groovy: Won't Fix Bug description: [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 Date: Wed, 29 Jan 2020 09:06:54 + 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 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
[Touch-packages] [Bug 1782984] Re: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications
If you want evidence that the libx11 1.7.0 fix works then the error reports linked from bug 1886059 are convincing enough to me. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libx11 in Ubuntu. https://bugs.launchpad.net/bugs/1782984 Title: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications Status in libx11 package in Ubuntu: Fix Released Status in libx11 source package in Bionic: Fix Committed Status in libx11 source package in Focal: Fix Committed Status in libx11 source package in Groovy: Won't Fix Bug description: [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 Date: Wed, 29 Jan 2020 09:06:54 + 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 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:
[Touch-packages] [Bug 1782984] Re: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications
Re comment #110, Cinnamon might just be missing the obvious: > [xcb] Most likely this is a multi-threaded client and XInitThreads has not been called We added XInitThreads to mutter in 3.36.2-2 and it is upstreamed in 3.36.3 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libx11 in Ubuntu. https://bugs.launchpad.net/bugs/1782984 Title: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications Status in libx11 package in Ubuntu: Fix Released Status in libx11 source package in Bionic: Fix Committed Status in libx11 source package in Focal: Fix Committed Status in libx11 source package in Groovy: Won't Fix Bug description: [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 Date: Wed, 29 Jan 2020 09:06:54 + 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 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
[Touch-packages] [Bug 1782984] Re: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications
That seems like we should be able to extract a verification from the errors.ubuntu.com results. Is it possible to query crashes with a specific dependency version? Seeing no crash reports with libx11 2:1.6.9-2ubuntu1.3 would suggest this is fixed. On the other hand, https://bugs.launchpad.net/ubuntu/+source/libx11/+bug/1782984/comments/110 suggests that this may *not* be fixed in focal. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libx11 in Ubuntu. https://bugs.launchpad.net/bugs/1782984 Title: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications Status in libx11 package in Ubuntu: Fix Released Status in libx11 source package in Bionic: Fix Committed Status in libx11 source package in Focal: Fix Committed Status in libx11 source package in Groovy: Won't Fix Bug description: [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 Date: Wed, 29 Jan 2020 09:06:54 + 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 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
[Touch-packages] [Bug 1782984] Re: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications
It's the top crasher of gnome-shell in focal, but I don't know a test case... https://errors.ubuntu.com/?release=Ubuntu%2020.04=gnome- shell=month -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libx11 in Ubuntu. https://bugs.launchpad.net/bugs/1782984 Title: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications Status in libx11 package in Ubuntu: Fix Released Status in libx11 source package in Bionic: Fix Committed Status in libx11 source package in Focal: Fix Committed Status in libx11 source package in Groovy: Won't Fix Bug description: [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 Date: Wed, 29 Jan 2020 09:06:54 + 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 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
[Touch-packages] [Bug 1782984] Re: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications
Thank you for the verification. Can someone also verify the focal version? This needs to be released for the newer series first before we can accept bionic. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libx11 in Ubuntu. https://bugs.launchpad.net/bugs/1782984 Title: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications Status in libx11 package in Ubuntu: Fix Released Status in libx11 source package in Bionic: Fix Committed Status in libx11 source package in Focal: Fix Committed Status in libx11 source package in Groovy: Won't Fix Bug description: [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 Date: Wed, 29 Jan 2020 09:06:54 + 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 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
[Touch-packages] [Bug 1782984] Re: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications
** Tags removed: verification-needed verification-needed-bionic ** Tags added: verification-done-bionic -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libx11 in Ubuntu. https://bugs.launchpad.net/bugs/1782984 Title: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications Status in libx11 package in Ubuntu: Fix Released Status in libx11 source package in Bionic: Fix Committed Status in libx11 source package in Focal: Fix Committed Status in libx11 source package in Groovy: Won't Fix Bug description: [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 Date: Wed, 29 Jan 2020 09:06:54 + 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 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:
[Touch-packages] [Bug 1782984] Re: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications
I have finally tested with Inkscape. No more freezes. For my computer this new package has solved the problem, a very annoying one. A lot of thanks. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libx11 in Ubuntu. https://bugs.launchpad.net/bugs/1782984 Title: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications Status in libx11 package in Ubuntu: Fix Released Status in libx11 source package in Bionic: Fix Committed Status in libx11 source package in Focal: Fix Committed Status in libx11 source package in Groovy: Won't Fix Bug description: [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 Date: Wed, 29 Jan 2020 09:06:54 + 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 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
[Touch-packages] [Bug 1782984] Re: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications
I have just installed the package libx11 2:1.6.4-3ubuntu0.5. I have made several tests with PCManFM, a program that used to freeze quite easily. IT WORKS, no more annoying freezing. I have to test with inkscape, another program that used to freeze easily, but I can't do it now. I'll make the tests in a few hours. Thanks you very much. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libx11 in Ubuntu. https://bugs.launchpad.net/bugs/1782984 Title: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications Status in libx11 package in Ubuntu: Fix Released Status in libx11 source package in Bionic: Fix Committed Status in libx11 source package in Focal: Fix Committed Status in libx11 source package in Groovy: Won't Fix Bug description: [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 Date: Wed, 29 Jan 2020 09:06:54 + 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 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
[Touch-packages] [Bug 1782984] Re: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications
I am also affected by this bug. I am running Linuxmint and Cinnamon just keeps crashing. Most of the times it is the result of clicking a few things and opening / closing guake at the same time. Installing the proposed packages does not fix the problem though, I am still encountering frequent crashes: (cinnamon:6385): Cogl-WARNING **: 15:11:23.728: Skipping layers 1..n of your pipeline since the first layer is sliced. We don't currently support any multi-texturing with sliced textures but assume layer 0 is the most important to keep [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. cinnamon: ../../src/xcb_io.c:260: poll_for_event: Zusicherung »!xcb_xlib_threads_sequence_lost« nicht erfüllt. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libx11 in Ubuntu. https://bugs.launchpad.net/bugs/1782984 Title: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications Status in libx11 package in Ubuntu: Fix Released Status in libx11 source package in Bionic: Fix Committed Status in libx11 source package in Focal: Fix Committed Status in libx11 source package in Groovy: Won't Fix Bug description: [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 Date: Wed, 29 Jan 2020 09:06:54 + 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 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
[Touch-packages] [Bug 1782984] Re: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications
Hello Stephen, or anyone else affected, Accepted libx11 into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/libx11/2:1.6.4-3ubuntu0.5 in a few hours, and then in the -proposed repository. Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed- bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification- failed-bionic. In either case, without details of your testing we will not be able to proceed. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. ** Changed in: libx11 (Ubuntu Bionic) Status: In Progress => Fix Committed ** Tags added: verification-needed-bionic -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libx11 in Ubuntu. https://bugs.launchpad.net/bugs/1782984 Title: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications Status in libx11 package in Ubuntu: Fix Released Status in libx11 source package in Bionic: Fix Committed Status in libx11 source package in Focal: Fix Committed Status in libx11 source package in Groovy: Won't Fix Bug description: [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 Date: Wed, 29 Jan 2020 09:06:54 + 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 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
[Touch-packages] [Bug 1782984] Re: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications
Hello Stephen, or anyone else affected, Accepted libx11 into focal-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/libx11/2:1.6.9-2ubuntu1.3 in a few hours, and then in the -proposed repository. Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed- focal to verification-done-focal. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification- failed-focal. In either case, without details of your testing we will not be able to proceed. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. ** Changed in: libx11 (Ubuntu Focal) Status: In Progress => Fix Committed ** Tags added: verification-needed verification-needed-focal -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libx11 in Ubuntu. https://bugs.launchpad.net/bugs/1782984 Title: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications Status in libx11 package in Ubuntu: Fix Released Status in libx11 source package in Bionic: In Progress Status in libx11 source package in Focal: Fix Committed Status in libx11 source package in Groovy: Won't Fix Bug description: [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 Date: Wed, 29 Jan 2020 09:06:54 + 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 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
[Touch-packages] [Bug 1782984] Re: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications
** 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 + Date: Wed, 29 Jan 2020 09:06:54 + + 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 + + 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 Touch seeded packages, which is subscribed to libx11 in Ubuntu. https://bugs.launchpad.net/bugs/1782984 Title: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications Status in libx11 package in
[Touch-packages] [Bug 1782984] Re: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications
** Changed in: libx11 (Ubuntu Focal) Status: Confirmed => In Progress ** Changed in: libx11 (Ubuntu Bionic) Status: Confirmed => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libx11 in Ubuntu. https://bugs.launchpad.net/bugs/1782984 Title: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications Status in libx11 package in Ubuntu: Fix Released Status in libx11 source package in Bionic: In Progress Status in libx11 source package in Focal: In Progress Status in libx11 source package in Groovy: Won't Fix Bug description: 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. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libx11/+bug/1782984/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1782984] Re: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications
The Groovy Gorilla has reached end of life, so this bug will not be fixed for that release ** Changed in: libx11 (Ubuntu Groovy) Status: Confirmed => Won't Fix -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libx11 in Ubuntu. https://bugs.launchpad.net/bugs/1782984 Title: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications Status in libx11 package in Ubuntu: Fix Released Status in libx11 source package in Bionic: Confirmed Status in libx11 source package in Focal: Confirmed Status in libx11 source package in Groovy: Won't Fix Bug description: 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. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libx11/+bug/1782984/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1782984] Re: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: libx11 (Ubuntu Bionic) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libx11 in Ubuntu. https://bugs.launchpad.net/bugs/1782984 Title: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications Status in libx11 package in Ubuntu: Fix Released Status in libx11 source package in Bionic: Confirmed Status in libx11 source package in Focal: Confirmed Status in libx11 source package in Groovy: Confirmed Bug description: 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. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libx11/+bug/1782984/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1782984] Re: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: libx11 (Ubuntu Groovy) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libx11 in Ubuntu. https://bugs.launchpad.net/bugs/1782984 Title: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications Status in libx11 package in Ubuntu: Fix Released Status in libx11 source package in Bionic: Confirmed Status in libx11 source package in Focal: Confirmed Status in libx11 source package in Groovy: Confirmed Bug description: 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. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libx11/+bug/1782984/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1782984] Re: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: libx11 (Ubuntu Focal) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libx11 in Ubuntu. https://bugs.launchpad.net/bugs/1782984 Title: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications Status in libx11 package in Ubuntu: Fix Released Status in libx11 source package in Bionic: Confirmed Status in libx11 source package in Focal: Confirmed Status in libx11 source package in Groovy: Confirmed Bug description: 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. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libx11/+bug/1782984/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1782984] Re: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications
** Changed in: libx11 (Ubuntu Bionic) Assignee: (unassigned) => Timo Aaltonen (tjaalton) ** Changed in: libx11 (Ubuntu Groovy) Assignee: (unassigned) => Timo Aaltonen (tjaalton) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libx11 in Ubuntu. https://bugs.launchpad.net/bugs/1782984 Title: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications Status in libx11 package in Ubuntu: Fix Released Status in libx11 source package in Bionic: New Status in libx11 source package in Focal: New Status in libx11 source package in Groovy: New Bug description: 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. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libx11/+bug/1782984/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1782984] Re: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications
** Changed in: libx11 (Ubuntu) Assignee: (unassigned) => Timo Aaltonen (tjaalton) ** Changed in: libx11 (Ubuntu Focal) Assignee: (unassigned) => Timo Aaltonen (tjaalton) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libx11 in Ubuntu. https://bugs.launchpad.net/bugs/1782984 Title: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications Status in libx11 package in Ubuntu: Fix Released Status in libx11 source package in Bionic: New Status in libx11 source package in Focal: New Status in libx11 source package in Groovy: New Bug description: 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. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libx11/+bug/1782984/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1782984] Re: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications
libx11 (2:1.7.0-1) unstable; urgency=medium * New upstream release. * patches: Refreshed. * signing-key: Added key from Keith Packard. * symbols: Updated. -- Timo Aaltonen Wed, 06 Jan 2021 20:47:58 +0200 ** Also affects: libx11 (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: libx11 (Ubuntu Groovy) Importance: Undecided Status: New ** Also affects: libx11 (Ubuntu Focal) Importance: Undecided Status: New ** Changed in: libx11 (Ubuntu Bionic) Importance: Undecided => High ** Changed in: libx11 (Ubuntu Focal) Importance: Undecided => High ** Changed in: libx11 (Ubuntu Groovy) Importance: Undecided => High ** Changed in: libx11 (Ubuntu) Status: Confirmed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libx11 in Ubuntu. https://bugs.launchpad.net/bugs/1782984 Title: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications Status in libx11 package in Ubuntu: Fix Released Status in libx11 source package in Bionic: New Status in libx11 source package in Focal: New Status in libx11 source package in Groovy: New Bug description: 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. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libx11/+bug/1782984/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1782984] Re: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications
Does anyone know if an update of the libx11 package for lubuntu 18.04 will be released? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libx11 in Ubuntu. https://bugs.launchpad.net/bugs/1782984 Title: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications Status in libx11 package in Ubuntu: Confirmed Bug description: 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. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libx11/+bug/1782984/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1782984] Re: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications
Fixed in libx11 version 1.7.0 with https://gitlab.freedesktop.org/xorg/lib/libx11/-/commit/dbb55e1a5e82870466b095097d9e46046680ec25 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libx11 in Ubuntu. https://bugs.launchpad.net/bugs/1782984 Title: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications Status in libx11 package in Ubuntu: Confirmed Bug description: 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. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libx11/+bug/1782984/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1782984] Re: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications
** No longer affects: pcmanfm (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libx11 in Ubuntu. https://bugs.launchpad.net/bugs/1782984 Title: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications Status in libx11 package in Ubuntu: Confirmed Bug description: 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. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libx11/+bug/1782984/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1782984] Re: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications
I think i got it right this time. I managed to apply the proposed libx11 patch, installed the right libx11 deb and it worked so far. If anyone willing to test the fix i pushed it to https://github.com/avafinger/libx11_1.6.4 Mind that if ubuntu team release a new version of the libx11 you might not get it installed and will need to reinstall the previous version. Cheers -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libx11 in Ubuntu. https://bugs.launchpad.net/bugs/1782984 Title: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications Status in libx11 package in Ubuntu: Confirmed Status in pcmanfm package in Ubuntu: Triaged Bug description: 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. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libx11/+bug/1782984/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1782984] Re: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications
The attachment "This patch is not the fix. WARNING" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team. [This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.] ** Tags added: patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libx11 in Ubuntu. https://bugs.launchpad.net/bugs/1782984 Title: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications Status in libx11 package in Ubuntu: Confirmed Status in pcmanfm package in Ubuntu: Triaged Bug description: 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. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libx11/+bug/1782984/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1782984] Re: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications
I applied the patch attached (libX11) but the crash still occurs with less frequency. Maybe i missed some additional patch required to fix this. For the record: I am running LUbuntu in this PC box (upgraded from 16.04 to 18.04) and i have another one with Ubuntu 18.04 + LXDE installed from scratch that doesn't get the error. Anything else i could try? ** Patch added: "This patch is not the fix. WARNING" https://bugs.launchpad.net/ubuntu/+source/pcmanfm/+bug/1782984/+attachment/5394608/+files/Fix-poll_for_response-race-condition.diff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libx11 in Ubuntu. https://bugs.launchpad.net/bugs/1782984 Title: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications Status in libx11 package in Ubuntu: Confirmed Status in pcmanfm package in Ubuntu: Triaged Bug description: 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. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libx11/+bug/1782984/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1782984] Re: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications
Ouch, I missed this commit: https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/34/diffs?commit_id=8b45f9589b3eb1ff46d16c774b017794e553db8e I Will try again. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libx11 in Ubuntu. https://bugs.launchpad.net/bugs/1782984 Title: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications Status in libx11 package in Ubuntu: Confirmed Status in pcmanfm package in Ubuntu: Triaged Bug description: 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. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libx11/+bug/1782984/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1782984] Re: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications
I would like to add some info that may help to narrow the problem. I have had this crash in PCManFM since i upgraded ubuntu from 16.04 to 18.04 but the same bug manifest in Geany and Chromium as well. The bug could hit PCManFM within a few clicks opening directories and then clicking on a file or can take hours to show up. In the case of Chromium it usually hit at the launch of the browser. I rebuilt the LibX11 with the supposedly fix mentioned by Tycho Kircher and apparently this has not fixed the problem but the crash is now without the Assertion `!xcb_xlib_threads_sequence_lost' failed. I installed only these packages: * libx11-xcb1_1.6.4-3ubuntu0.2_amd64.deb * libx11-xcb-dev_1.6.4-3ubuntu0.2_amd64.deb lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description:Ubuntu 18.04.4 LTS Release:18.04 Codename: bionic -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libx11 in Ubuntu. https://bugs.launchpad.net/bugs/1782984 Title: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications Status in libx11 package in Ubuntu: Confirmed Status in pcmanfm package in Ubuntu: Triaged Bug description: 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. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libx11/+bug/1782984/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1782984] Re: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications
** Summary changed: - PCManFM freezes with Assertion `!xcb_xlib_threads_sequence_lost' failed when clicking on a file or folder in 18.04 + Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libx11 in Ubuntu. https://bugs.launchpad.net/bugs/1782984 Title: Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications Status in libx11 package in Ubuntu: Confirmed Status in pcmanfm package in Ubuntu: Triaged Bug description: 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. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libx11/+bug/1782984/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
