Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications

Looking into this a bit later when I do some real hardware testing.

Thanks for the bug report.

Hi,

I can confirm this bug .. on Lubuntu 18.04 ...
I already had the same one on Lubuntu 17.04 ...
PCManFM unexpectedly closes when you open a folder and it seems to be more common when the option 'Preserve directory's settings' is enabled

Same bug here.
After upgrading to Lubuntu 18.04, pcmanfm crashes unexpectedly with the same error message (No such file or directory: '/etc/xdg/pcmanfm/Lubuntu/lubuntu.conf').

Status changed to 'Confirmed' because the bug affects multiple users.

Never had this until 18.04. Now it happens on several 64 and 32 bit Lubuntu installs, as well as Ubuntu installs where I've added LXDE.

I don't get any error message, it just freezes (mouse still moves) and after a minute or so the "has stopped responding" box pops up.

I have the same problem with my installation of Lubuntu 18.04.01 LTS on my Shuttle Barebone PC. When using it with my samba share from a NAS in my LAN it crashes a lot.

Also, the icon of PCmanFM in the LXPanel 0.9.3 is not blue but black. If I uptick the heigh of the icons in the panel then the icon becomes blue, when I change it back to its original smaller size it stays blue. But then it changes to black again some time later.

Same problem here on 18.04 (and previous versions). Crashes often for no special reason. Is there a more stable alternative?

Same problem here with Lubuntu Bionic (18.04.01 LTS 64bit Desktop). PcManFM crashes quite often when accessing folders or files, it seems like a timing problem. There is no any rule of freezing. It is random and it seems is not depending on any action or background activity.
The PcManFM window becomes suddenly unresponsive, virtually it freezes. Eg. it shows the latest hint permanently, no reaction to anything.
When an instance crashes, all the other opened instances become unresponsive without any sign.
Starting a new instance of PcManFM after the crash, it closes all of the frozen instances, and the new one works well. ... for a while.
But never crashes during actions (Copying, Moving, Deleting...etc).
It crashes only when accessing a file or folder by a mouse-click.

Previous version I used are absoulutely OK. (Lubuntu 16.04.xx LTS.)

Thank you in advance,
Regards.

I want to add, that I love PCmanFM above all other options! We need this to work! The clean surface of PCmanFM fits perfectly into Lubuntu. It was a blessing to work with it. There is no clean alternative.

I have some additional information regarding the crash. I use a samba share with mp3fs on it. This is a file system that transfers files to mp3 upon access (https://khenriks.github.io/mp3fs/).

Janos Verebes wrote that PCmanFM does not crash while performing actions. I have made the experience that it does crash the connection to the file system while copying from that special file system. This results in a broken mount point on the samba share - broken in the sense that "ls -all" shows "?????" on permission rights and user/group. I have then to unmount it and mount it again.

I am not 100% sure if the file system/mount point crashes because of PCmanFM, though. PCmanFM does not crash in the sense that the UI gets unresponsive. But I have the feeling both isses are related. I never had troubles using mp3fs before upgrading to 18.04.

So important question: which filesystem(s) is this happening with?

Agreeing with Ben I can confirm the situation.
When multiple instances of PcManFM run and one of them freezes by accessing a file by user as it has been described above, other instances' windows become unresponsive, but seemingly the running processes (eg. copying) run in the background. One time I waited until a copying process may end to not to ruin the USB file system, and it seemed the copying process finished successfully despite the UI became frozen. So I think the background processes are running despite the file manager window is frozen.

The freezing may be more frequent when using an USB stick drive or something like that, but it is not depend on the media, but may be the problem occures more frequently then.

As a quick response to Walter's important question as I see freezing of PcManFM is not really file system dependent. For me it freezes with NTFS, FAT32, FAT16 (USB sticks) and EXT4 file systems (Lubuntu installed) either. Tested hardware background is a HP Elite 8300 Pro and HP 6300 Pro. Both of the machines uses Pentium G processors with intel Q75 and Q77 chip sets which are nearly the same.
With previously used version 16.04 LTS everything worked perfectly without any error.
Since I know PCManFM is much more than a file manager in Lubuntu systems, it is the base of the whole system handler, Desktop...etc. That's why it is strange when file manager window freezes every other component work along.
As an addendum, using the new Swap policy - when the system handles the swap as a file, the GIMP graphics editor closes suddenly without any sign. Maybe the swap handler can not satisfy GIMP's quite big swap needs. But I don't know. Using the old Swap method, when I use a part of the HDD as a swap area (about 30GB for 12GB Ram installed) GIMP seems to work well. I don't know whether the new Swap handling affects PCManFM crash story or not.

Ok, so at least several filesystems do have this problem.

To get at the bottom of this, we need to be very careful about conflating issues together. There may be some other things that are possibly related, but let's not jump there quite yet. First we need to identify the nature of the problem. Let's stick to one particular set of symptoms triggered by a specific set of actions.

That said, many questions remain:

 1. To reproduce, what conditions are necessary and exactly what do I need to do to to make this happen?
 2. What are the actual results? I see mentions of freezing and crashing, sometimes both, but those are very different things.
 3. Is this only on upgraded versions? Do new installs have the same situation?
 4. Any errors in /var/log/syslog, `dmesg`?
 5. Any output from pcmanfm itself if run from the command line? `killall pcmanfm && pcmanfm --desktop --profile lubuntu` should do the trick.
 6. Does this only happen on real hardware or can this be reproduced on a virtual machine?

In an ideal world, this would be testable on a virtual machine and one could just boot up the live system of bionic and perform a particular set of steps and see the actual symptoms. Random things are incredibly hard (let's say virtually impossible) to fix, especially if no particular errors are shown. That said, until we can figure out the above, I've set the bug to incomplete.

I suspect the error about the conf file is a red herring, by the way. Using `strace` on pcmanfm it looks for several possible config files before it finds what it's looking for and this is not uncommon.

Not found:
openat(AT_FDCWD, "/etc/xdg/xdg-Lubuntu/libfm/libfm.conf", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/home/lubuntu/.config/libfm/dir-settings.conf", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/xdg/lubuntu/pcmanfm/lubuntu/pcmanfm.conf", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/xdg/xdg-Lubuntu/pcmanfm/lubuntu/pcmanfm.conf", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/home/lubuntu/.config/pcmanfm/lubuntu.conf", O_RDONLY) = -1 ENOENT (No such file or directory)

Found:
openat(AT_FDCWD, "/etc/xdg/libfm/libfm.conf", O_RDONLY) = 8
openat(AT_FDCWD, "/etc/xdg/lubuntu/libfm/libfm.conf", O_RDONLY) = 8
openat(AT_FDCWD, "/home/lubuntu/.config/libfm/libfm.conf", O_RDONLY) = 8
openat(AT_FDCWD, "/home/lubuntu/.config/user-dirs.dirs", O_RDONLY) = 12
openat(AT_FDCWD, "/etc/xdg/pcmanfm/lubuntu/pcmanfm.conf", O_RDONLY) = 12
openat(AT_FDCWD, "/home/lubuntu/.config/pcmanfm/lubuntu/pcmanfm.conf", O_RDONLY) = 12
openat(AT_FDCWD, "/home/lubuntu/.config/pcmanfm/lubuntu/desktop-items-0.conf", O_RDONLY) = 12
openat(AT_FDCWD, "/home/lubuntu/.config/pcmanfm/lubuntu/desktop-items-0.conf", O_RDONLY) = 13

Dear Walter,
I understood everything you wrote. I can promise tomorrow I will do a clean install of Lubuntu 18.04 on a HP Desktop AMD X2 250 machine and avoid any upgrade, and I will test the behavior of the file manager. As I remember - on an updated system of course - the problem came up more frequently when an USB device was connected to the system. Eg. an USB hub with an USB stick inserted in.
Tomorrow I'll test it again. The freezing is not occurred only when I clicked a file on the USB stick but I clicked any of the files or folders anywhere system-wide or even SAMBA shares.
Now, when I tried to describe the freezing to you, PCManFM just freezes when just clicking here-and-there now in the /var/log folder... You can see the click not selects the file, not changes its color as selected, and the black backgrounded hint freezes on the window. Then clicking on an other window, PCManFM file manager instance vanishes. I open the syslog to see what happened: No, there is nothing new in the syslog as if nothing had happened. Now there is no any external drive or device connected to the machine. Uhhhh.. it's a hard thing!

Thank you for the kind helpfulness.

Thanks Janos. I think if we are persistent and approach this scientifically, we can figure it out. If you can figure out some hint (e.g. the USB) start eliminating variables and applying it to multiple situations. When we can find something consistent, we'll be on our way.

The other thing we can try to do is doing an strace. The problem is that is going to be really "chatty" so if we can nail this down to a set of steps we can perform quickly, it will be less of an issue of finding a needle in the world's biggest haystack.

Dear Walter,

In last two days I haven't got time to look around in the topic, but I discussed this problem with colleagues who develop softwares for instruments using Linux, asking for their opinion. They told me if the file operations remain alive after window crashing, it can mean the problem must be a window manager problem instead of problem of the file manager itself. I appreciate their opinion, so first of all I will check the live CD with "Try Lubuntu" function, which is the purest version of Lubuntu without extra packages. If the problem comes up, we will get closer to the solution.. So tomorrow.

Thanks for your help,
Regards,
Janos

Dear Walter,

So here I am with the test result.
Starting only the Live CD without any extra driver, software, etc...

I don"t really know whether it is a bad news or good:
It does produce the freezing also.

The situation we can see is just the same, black backgrounded file-hint stuck on the screen, no window-handler response, waiting a while, then all the PcManFM instances vanish with no log of any problem.

With this test I wanted to make sure the problem is not because of an extra not-so-compatible driver or window compositing.

I have made the test on Lubuntu 18.04.1 amd64 release.
Test machine was my HP Elite Pro 8300 (Pentium G2030 processor @ 3 GHz, 12GB of DDR3 ram @ 1333MHz) Winchester was not affected in any situation using the LiveCD function.

On Monday I will perform this test on an AMD X2 machine also.

Best regards,
Janos

In regards to actually fixing the bug, this is great news. This means that I should be able to reproduce it myself. Can you give me clear steps to follow, especially with the default ext4 filesystem? That will make it even easier if there are no special conditions.

Dear Walter,

There is no special conditions, only boot from USB or CD with Lubuntu 18.04 LTS on it, and choose "Try Lubuntu" function instead of "Install Lubuntu". There is no need to use a HDD or SSD either.

There, when Desktop completes, click on the "File manager" icon in the upper left corner, and there I started another instance, and started to just clicking around or try to copy any folder into for example to Documents folder.. When I tried to click on the target directory I got a freeze then vanishing. Checking for the log in folder you mention above, there was nothing about the crash.

It seems the Task Manager shuts down PcManFM since it is not responding. In Live CD (Try Lubuntu) mode - before any installation - all the tasks run in the main memory, so it is dependent none of the installed file systems. By the way normally I use Ext4, but in this situation it really doesn't matter.

Regards,
Janos

Dear Walter,

Just a little addendum.
When PcManFM freezes, all the running instances of it freezing, however their windows are manageable which means minimizing, maximizing, moving are working but telling the truth wen maximizing of course it doesn't show any window content since the program is not responding. It is closing which is not working since the task manager cannot send the normal close command. Then the task manager sends a message the program is not responding.

When starting a new instance of PCManFm before this message appear, all the instances vanish from the screen, and the new one will work correctly until the next crash.

Thank You,
Best wishes,
Janos

Here's what I tried based on my interpretation of your steps to follow:

 1. Boot 18.04.1
 2. Select "Try Lubuntu"
 3. Right click on the "Trash" icon at the upper left, click "Open in New Window"
 4. Repeat step 3
 5. Open the task manager to keep an eye on things
 6. In one of the PCManFM windows (let's call this Window A), click "Home Folder"
 7. Right click, "Create > New Folder", take the default name ("New")
 8. In the other window (let's call this Window B), click "Home Folder"
 9. Open the "Documents" folder
10. From Window A, drag "New" folder onto Window B ("Documents")
11. In Window B, drag "New" folder back onto Window B ("Home Folder")

At no point was there any freezing or even really reduced performance.

This was in a virtual machine, so maybe that's part of the problem, but I think it's more likely that the issue is that clear steps to reproduce aren't there.

Dear Walter,

Unfortunately you are right,
There is no clear steps to get a freeze. It is completely stochastic, depends on no special steps. Whenever it thinks it freezes. Strange because of no other program freezes, window managing seems to be OK, in this way I have to thing the problem is when accessing file elements. And it happens even when just perform a one-left-clink on a file single file or folder.
The question is, what happens when a left-click performed. It accesses file or just a screen function (but probably the first one.) ?
So today I perform a clean test on a real machine booting a LiveCD but now on an AMD X2 250 system - to avoid the question of any specific processor timing problem. (Since Pentium G has a 3 level cache while AMD has the good old architecture).

Thanks and best wishes,
Janos

Dear Walter,

I have the results from HP machine with AMD Athlon II 250 processor and 4GB Ram.

After booting Live CD and starting PcManFM I nearly immediately got the crash.
Apport function dropped up a "System Program Error Detected" window, then I succeeded to save some logs from /var/log and /var/crash.
If any of them can be helpful I can send you... if I can get an e-mail address or sg. like that. In /var/crash there is a 10,1MB sized "_usr_bin_pcmanfm.999.crash" log also.

And some more words: Since AMD machine is a bit slower than Intel G machine, after the freezing - in the waiting time - I could start another instance of PcManFM which also started frozen, then all the instances vanished. Only after vanishing I could start a new, yet working instance.

Regards,
Janos

You should be able to attach the files here. The .crash will likely be the most useful.

OK, thanks, Here I send all the saved logs include the .crash file syslog, kern.log etc.

Just a little update,
clicking the "Go to parent directory" (Up arrow) in PcManFM window I got a crash also. So not the file or directory clicking cause crash only.

Thanks,
Janos

A new Crash file (/var/crash/)is available from an istalled Lubutnu 18.04.1 64 bit desktop version.
The situation is just the same, when accessing a directory, PcManFM window freezes.

Regards,
Janos

Important News!

Trying find an other file-handling solution instead of PcManFM, I installed Thunar on Lubunu 18.04.1 LTS,

AND IT DOES JUST THE SAME KIND OF FREEZING !!!!

Accessing directory or file it freezes.
Unfortunately there is no crash report so far...
But the situation is just the same.
That can easily mean the problem is not a PCManFm problem.

The topic seems to be a bit abandoned suggesting all is good as it is not.

A little workaround since PCManFM handles the desktop well, to install CAJA file manager with its plugins (originally comes with Mate desktop). As I work with it for about two weeks it seems to be OK. No freeze, no problem with Lubuntu 18.04.1 LTS.
 I am one of those who are enjoying lightning speed and great scalability of Lubuntu for years, and it would be really sad having to give it up and change to a "maybe shinier" but much slower desktop. I want to try anything to bring it back to life since PcManFM is my favorite, but editing, renaming, copying, moving lot of files as I do makes this freezing problem quite an annoying and somehow dangerous. Until a reliable solution comes up I work with Caja as a second possibility of file managing.

If any of "suffering" Lubuntu Bionic users is interested in using caja and its plugins, install the following packages:

sudo apt install caja caja-open-terminal caja-extensions-common caja-actions caja-image-converter mate-terminal caja-rename engrampa

("mate-terminal" is for "Open terminal here" function, and "engrampa" archive manager is for "create-archive" function.)

Thanks, Regards,
Janos

Thanks for the information! I tried to copy via terminal from my samba share and this also crashed my mount point of the mp3fs on the share the same way as with using PCmanFM. I am not an expert, but maybe the problem is not related to PCmanFM but more deeply in the kernel?

Hi Ben,
Recently I had problem with Samba share, but with a little workaround I managed to solve the problem.
Since Samba is also modified in Ubuntu 18.04 it is needed to look for your problem. Using Caja I have no problem like I had with PcManFM, but no mention it is a deeper problem because Thunar freezes also with Lubuntu 18.04.

Just for a try I share my Samba workaround with you, maybe you will find something different between your and my packages or configuration.

Let us see:

The way I installed Samba for enable and handle sharing is:
sudo apt-get install libgnomevfs2-extra samba-common samba-common-bin winbind libpam-winbind libnss-winbind libgnomevfs2-bin fam gnome-mime-data samba python-glade2 system-config-samba smbclient cifs-utils heimdal-clients

then after making my network seetings (Host name, Workgroup) ...
edit /etc/samba/smb.conf

and go to the Global Settings section
(under global these two new lines enables file manager to see and browse Samba shares, the line at the bottom "client max protocol = NT1" sets the protocol as it worked well in lubuntu 16.04 ).
So make the following modifications like this below:

#======================= Global Settings =======================
[global]

client use spnego = no
client NTLMv2 auth = no

## Browsing/Identification ###
# Change this to the workgroup/NT-domain name your Samba server will part of
   workgroup = WORKGROUP
   client max protocol = NT1

Save the file,
Then give this another try with Caja! ...and of course don't forget to write your experiences :)
It works for me like a charm.
Formerly I used package GAMIN (which caused problems) instead of FAM. Since using FAM there is no problem.

For me PcManFM and Thunar freeze even when accessing local files, caja seems to solve the problem so far. However PcManFM is faster, better, etc... but since it freezes, I am not brave enough to handle my files with it.

Ps: and an other great plugin for caja is caja-rename which gives caja a really powerful bulk renaming function.
sudo apt install caja-rename

Regards,
Janos

PCManFM 1.3.0.1 on Lubuntu 18.04.1 LTS

Thinking a big, I looked for PCManFM 1.3.0.-1 at launchapd.net:

https://launchpad.net/ubuntu/cosmic/arm64/pcmanfm/1.3.0-1

and downloaded the .deb file below from the "Downloadable files" section here:

http://launchpadlibrarian.net/368633026/pcmanfm_1.3.0-1_arm64.deb

Surprisingly all the dependencies are satisfied, so no modifications needed to use this file with Lununtu 18.04.1

And tested...

No freeze so far, however I've made a bunch of file operations.
I continue testing for some days, I will write my experiences.

Regards,
Janos

Sorry, the links I gave (in previous message) are bad.

Now, the good ones again.

First is for launchpad.net:

https://launchpad.net/ubuntu/cosmic/amd64/pcmanfm/1.3.0-1

And the second one is for the download link (amd64 achitecture):

http://launchpadlibrarian.net/368631138/pcmanfm_1.3.0-1_amd64.deb

Sorry again for the inconvenience.

Hello,

Does this happen on Lubuntu 16.04 as well? What about 14.04?

Once we have this knowledge and once I can reproduce it, I can go about Git bisecting the commit which caused this, so I can then analyze the changes between the 18.04 copy and the 18.10 copy (if that does indeed work) and find the fix.

If I can't reproduce this, it will be much harder, but it's a step in the right direction regardless.

Thanks everyone for your time working on this bug.

Hello,

Answering Simon's question: No, on 16.04 and 14.04 everything is OK !!!!
The problem started (as it is mentioned by "prrvchr" up above at message #3) from Lubuntu release 17.10, which I can not confirm, since I never used 17.10. I use mostly the LTS releases.
But I can strongly confirm the problem with 18.04.
I help you of course, the problem is also mine, since I'm a Lubuntu fanatic :)
and I really want it to work well.

To Walter:

Maybe, but I can only tell my experience, Thunar produces just the same kind of freeze as PcManFM. Trying Thunar in original Xubuntu Bionic I could not recognize the freezing, however I don't like Xubuntu. There are many other hard things with that... which are always leading me back to Lubuntu. :)

But what I found, I was able to upgrade PCManFM 1.2.5 to the version 1.3.0 (comes with Cosmic) from Lauchpad.net
This new version can use Bionic's original Libfm 1.2.5 without any problem.
I've used it about for a week and
THERE IS NO MORE FREEZING. EVERYTHING IS WORKING WELL.

I'm really curious what is the difference between 1.2.5 and 1.3.0 ?

Caja also works with Lubuntu Bionic well, without any problem, no freezing.

I have only tried Lubuntu Bionic yet.

My gvfs version:
****************
gvfs:amd64 1.36.1-0ubuntu1.1
gvfs-backends 1.36.1-0ubuntu1.1
gvfs-bin 1.36.1-0ubuntu1.1
gvfs-common 1.36.1-0ubuntu1.1
gvfs-daemons 1.36.1-0ubuntu1.1
gvfs-fuse 1.36.1-0ubuntu1.1
gvfs-libs:amd64 1.36.1-0ubuntu1.1

My libglib version:
*******************
libglib-object-introspection-perl 0.044-2
libglib-perl 3:1.326-1build1
libglib2.0-0:amd64 2.56.2-0ubuntu0.18.04.2
libglib2.0-bin 2.56.2-0ubuntu0.18.04.2
libglib2.0-cil 2.12.40-2
libglib2.0-data 2.56.2-0ubuntu0.18.04.2
libglibmm-2.4-1v5:amd64 2.56.0-1

Regards,
Janos

Hi! I am not a linux expert but I'm having the crashes with PCManFM too, all the time. I rarely, if ever had them on Lubuntu 16.04.

RE: "I'm really curious what is the difference between 1.2.5 and 1.3.0?"

Here is the diff on the launchpad page:
http://launchpadlibrarian.net/368644982/pcmanfm_1.2.5-3ubuntu1_1.3.0-1.diff.gz

From this page:
https://launchpad.net/ubuntu/+source/pcmanfm/1.3.0-1

Hopefully this helps :) I hope you all have a great day and thank you for your efforts on this!
-Mike

The Groovy Gorilla has reached end of life, so this bug will not be fixed for that release

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.

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.

All autopkgtests for the newly accepted libx11 (2:1.6.4-3ubuntu0.5) for bionic have finished running.
The following regressions have been reported in tests triggered by the package:

awesome/4.2-4 (amd64, i386, arm64, s390x, ppc64el)
openssh/1:7.6p1-4ubuntu0.5 (ppc64el)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/bionic/update_excuses.html#libx11

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

All autopkgtests for the newly accepted libx11 (2:1.6.9-2ubuntu1.3) for focal have finished running.
The following regressions have been reported in tests triggered by the package:

saods9/8.1+repack-1 (amd64)
lazarus/2.0.6+dfsg-3 (armhf)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/focal/update_excuses.html#libx11

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

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.

I am running Linux Mint 20.2 Uma and have the libx11 packages installed with version 2:1.6.9-2ubuntu1.3

Edit: interestingly I can almost always reproduce the crash when unlocking the screen.

Edit2: I found a workaround: switching off high-dpi and reducing the resolution overall by a factor of 2 solved the Problem for me.
I am wondering if this is the wrong bug I am chasing.

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.

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.

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.

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&package=gnome-shell&period=month

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.

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

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.

> 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!

comment #113 still holds, focal needs to be verified first

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.

Any update on this bug and the status of focal?

Same error here:
PCManFM 1.3.1-1
Ubuntu 20.04.2.0 LTS "Focal Fossa" - Release amd64 (20210209.1)
Desktop: LXDE

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!

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?

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.

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?

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.

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.

did you enable focal-proposed?

I am using docker file to get ubuntu 20.04 and install packages. How can I enable focal-proposed insider docker?

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.

or do as advised in comment #106

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 \

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

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/*

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.

Please ensure your application is calling XInitThreads before commenting here. If it's not calling XInitThreads then that's probably an application bug.

The version of libx11 in the proposed pocket of Bionic that was purported to fix this bug report has been removed because the target series has reached its End of Life.