Bug #1872527 “Clipboard doesn't work 100% of the time in Ubuntu ...” : Bugs : virt-manager package : Ubuntu

Revision history for this message

John Morrison (johnmorrison) wrote on 2020-04-13:

#1

Dependencies.txt Edit (12.0 KiB, text/plain; charset="utf-8")
ProcCpuinfoMinimal.txt Edit (1.1 KiB, text/plain; charset="utf-8")
ProcEnviron.txt Edit (107 bytes, text/plain; charset="utf-8")

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2020-04-15:

#2

Hi John,
just to be clear we are not talking about copy&paste between guest and host but copy&paste inside the guest right?.

I was installing `screenkey` to check if the events arrive at the guest as I type them (they did).

At the same time in the background I was displaying the clipboard content via:
  while /bin/true; do clear; printf "primary: '%s'\nclipboard: '%s'\n" \
    "$(xclip -o -selection primary)" \
    "$(xclip -o -selection clipboard)"; sleep 0.1; done

Note: this doesn't need "Kubuntu" it seemd to trigger with "normal" Ubuntu and the default "editor" as well.

I found some odd behavior, sometimes it would seem as if my copy would not work.
Pasting then would paste "nothing" later on if I copy something again it would "free up" and unblock all old calls, suddenly pasting all of them.

Example
text editor with:
aa
bb
cc
Then I copy "aa" but the system locks up.
I go to the next line and try to paste it three times (nothing happens).
Then I copy "bb" which "unblocks" the system.
The three times "aa" paste now appear at once.

I found that in these blocked copy actions xclip seemes to get into a hang.
That might be used to debug what actually goes on.

From a qemu perspective the responsibility stops once the key-events are delivered and screenkey shows all my copy/paste keyboard inputs. I'm re-assigning that to the Desktop Team for triage on their side as it leaves my comfort zone after these key events are delivered.

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2020-04-15:

#3

The hanging call inside the bad-case is:
$ xclip -o -selection clipboard

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2020-04-15:

#4

Download full text (28.9 KiB)

strace of hanging xclip

0.000000 execve("/usr/bin/xclip", ["xclip", "-o", "-selection", "clipboard"], 0x7ffd7ad09828 /* 61 vars */) = 0 <0.000898>
     0.001835 brk(NULL) = 0x563a24c98000 <0.000265>
     0.000754 arch_prctl(0x3001 /* ARCH_??? */, 0x7fff9ddd2c00) = -1 EINVAL (Invalid argument) <0.000419>
     0.001283 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) <0.000129>
     0.000422 openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 <0.000147>
     0.000300 fstat(3, {st_mode=S_IFREG|0644, st_size=60213, ...}) = 0 <0.000047>
     0.000245 mmap(NULL, 60213, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f160b81f000 <0.000365>
     0.000542 close(3) = 0 <0.001195>
     0.001544 openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libXmu.so.6", O_RDONLY|O_CLOEXEC) = 3 <0.000238>
     0.000487 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240p\0\0\0\0\0\0"..., 832) = 832 <0.000071>
     0.000273 fstat(3, {st_mode=S_IFREG|0644, st_size=111104, ...}) = 0 <0.000061>
     0.000174 mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f160b81d000 <0.000049>
     0.000205 mmap(NULL, 114232, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f160b801000 <0.000053>
     0.000189 mprotect(0x7f160b807000, 81920, PROT_NONE) = 0 <0.000055>
     0.000144 mmap(0x7f160b807000, 61440, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6000) = 0x7f160b807000 <0.000074>
     0.000155 mmap(0x7f160b816000, 16384, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x15000) = 0x7f160b816000 <0.000066>
     0.000143 mmap(0x7f160b81b000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x19000) = 0x7f160b81b000 <0.000049>
     0.000186 close(3) = 0 <0.000041>
     0.002530 openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libX11.so.6", O_RDONLY|O_CLOEXEC) = 3 <0.000215>
     0.000412 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\300\220\1\0\0\0\0\0"..., 832) = 832 <0.000052>
     0.000216 fstat(3, {st_mode=S_IFREG|0644, st_size=1293928, ...}) = 0 <0.000060>
     0.000206 mmap(NULL, 1297720, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f160b6c4000 <0.000060>
     0.000156 mprotect(0x7f160b6dc000, 1179648, PROT_NONE) = 0 <0.000133>
     0.000236 mmap(0x7f160b6dc000, 569344, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x18000) = 0x7f160b6dc000 <0.000067>
     0.000151 mmap(0x7f160b767000, 606208, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xa3000) = 0x7f160b767000 <0.000063>
     0.000140 mmap(0x7f160b7fc000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x137000) = 0x7f160b7fc000 <0.000063>
     0.000228 close(3) = 0 <0.000058>
     0.000166 openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 <0.000040>
     0.003473 read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360q\2\0\0\0\0\0"..., 832) = 832 <0.000025>
     0.000065 pread64(3, "\6\0\0\0\4\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0"..., 784, 64) = 784 <0.000015>
     0.000044 pread64(3, "\4\0\0\0\20\0\0\0\5\0\0\0GNU\0\2\0\0\300\4\0\0\0\3\0\0\0\0\0\0\0", 32, 848) = 32 <0.000013>
    ...

strace of hanging xclip

0.000000 execve("/usr/bin/xclip", ["xclip", "-o", "-selection", "clipboard"], 0x7ffd7ad09828 /* 61 vars */) = 0 <0.000898>
     0.001835 brk(NULL)                 = 0x563a24c98000 <0.000265>
     0.000754 arch_prctl(0x3001 /* ARCH_??? */, 0x7fff9ddd2c00) = -1 EINVAL (Invalid argument) <0.000419>
     0.001283 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) <0.000129>
     0.000422 openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 <0.000147>
     0.000300 fstat(3, {st_mode=S_IFREG|0644, st_size=60213, ...}) = 0 <0.000047>
     0.000245 mmap(NULL, 60213, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f160b81f000 <0.000365>
     0.000542 close(3)                  = 0 <0.001195>
     0.001544 openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libXmu.so.6", O_RDONLY|O_CLOEXEC) = 3 <0.000238>
     0.000487 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240p\0\0\0\0\0\0"..., 832) = 832 <0.000071>
     0.000273 fstat(3, {st_mode=S_IFREG|0644, st_size=111104, ...}) = 0 <0.000061>
     0.000174 mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f160b81d000 <0.000049>
     0.000205 mmap(NULL, 114232, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f160b801000 <0.000053>
     0.000189 mprotect(0x7f160b807000, 81920, PROT_NONE) = 0 <0.000055>
     0.000144 mmap(0x7f160b807000, 61440, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6000) = 0x7f160b807000 <0.000074>
     0.000155 mmap(0x7f160b816000, 16384, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x15000) = 0x7f160b816000 <0.000066>
     0.000143 mmap(0x7f160b81b000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x19000) = 0x7f160b81b000 <0.000049>
     0.000186 close(3)                  = 0 <0.000041>
     0.002530 openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libX11.so.6", O_RDONLY|O_CLOEXEC) = 3 <0.000215>
     0.000412 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\300\220\1\0\0\0\0\0"..., 832) = 832 <0.000052>
     0.000216 fstat(3, {st_mode=S_IFREG|0644, st_size=1293928, ...}) = 0 <0.000060>
     0.000206 mmap(NULL, 1297720, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f160b6c4000 <0.000060>
     0.000156 mprotect(0x7f160b6dc000, 1179648, PROT_NONE) = 0 <0.000133>
     0.000236 mmap(0x7f160b6dc000, 569344, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x18000) = 0x7f160b6dc000 <0.000067>
     0.000151 mmap(0x7f160b767000, 606208, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xa3000) = 0x7f160b767000 <0.000063>
     0.000140 mmap(0x7f160b7fc000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x137000) = 0x7f160b7fc000 <0.000063>
     0.000228 close(3)                  = 0 <0.000058>
     0.000166 openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 <0.000040>
     0.003473 read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360q\2\0\0\0\0\0"..., 832) = 832 <0.000025>
     0.000065 pread64(3, "\6\0\0\0\4\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0"..., 784, 64) = 784 <0.000015>
     0.000044 pread64(3, "\4\0\0\0\20\0\0\0\5\0\0\0GNU\0\2\0\0\300\4\0\0\0\3\0\0\0\0\0\0\0", 32, 848) = 32 <0.000013>
     0.000040 pread64(3, "\4\0\0\0\24\0\0\0\3\0\0\0GNU\0q\277\20\32\317\327\337\334\235q\223a\2778y{"..., 68, 880) = 68 <0.000017>
     0.000045 fstat(3, {st_mode=S_IFREG|0755, st_size=2029224, ...}) = 0 <0.000014>
     0.000043 pread64(3, "\6\0\0\0\4\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0"..., 784, 64) = 784 <0.000013>
     0.000041 pread64(3, "\4\0\0\0\20\0\0\0\5\0\0\0GNU\0\2\0\0\300\4\0\0\0\3\0\0\0\0\0\0\0", 32, 848) = 32 <0.000014>
     0.000040 pread64(3, "\4\0\0\0\24\0\0\0\3\0\0\0GNU\0q\277\20\32\317\327\337\334\235q\223a\2778y{"..., 68, 880) = 68 <0.000013>
     0.000039 mmap(NULL, 2036952, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f160b4d2000 <0.000023>
     0.000289 mprotect(0x7f160b4f7000, 1847296, PROT_NONE) = 0 <0.000035>
     0.000076 mmap(0x7f160b4f7000, 1540096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x25000) = 0x7f160b4f7000 <0.000632>
     0.000751 mmap(0x7f160b66f000, 303104, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x19d000) = 0x7f160b66f000 <0.000188>
     0.000287 mmap(0x7f160b6ba000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1e7000) = 0x7f160b6ba000 <0.000070>
     0.000116 mmap(0x7f160b6c0000, 13528, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f160b6c0000 <0.000017>
     0.000056 close(3)                  = 0 <0.000069>
     0.000146 openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libXt.so.6", O_RDONLY|O_CLOEXEC) = 3 <0.000064>
     0.000105 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0201\1\0\0\0\0\0"..., 832) = 832 <0.000015>
     0.000062 fstat(3, {st_mode=S_IFREG|0644, st_size=425552, ...}) = 0 <0.000013>
     0.000047 mmap(NULL, 2523872, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f160b269000 <0.000016>
     0.000041 mprotect(0x7f160b2cb000, 2097152, PROT_NONE) = 0 <0.000016>
     0.000040 mmap(0x7f160b4cb000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x62000) = 0x7f160b4cb000 <0.000016>
     0.000047 mmap(0x7f160b4d1000, 736, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f160b4d1000 <0.000015>
     0.000048 close(3)                  = 0 <0.000013>
     0.000045 openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libXext.so.6", O_RDONLY|O_CLOEXEC) = 3 <0.000019>
     0.000047 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340E\0\0\0\0\0\0"..., 832) = 832 <0.000014>
     0.000040 fstat(3, {st_mode=S_IFREG|0644, st_size=81600, ...}) = 0 <0.000013>
     0.000040 mmap(NULL, 84152, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f160b254000 <0.000016>
     0.000041 mmap(0x7f160b258000, 45056, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x4000) = 0x7f160b258000 <0.000019>
     0.000043 mmap(0x7f160b263000, 16384, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xf000) = 0x7f160b263000 <0.000016>
     0.000041 mmap(0x7f160b267000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x12000) = 0x7f160b267000 <0.000015>
     0.000050 close(3)                  = 0 <0.000014>
     0.000043 openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libxcb.so.1", O_RDONLY|O_CLOEXEC) = 3 <0.000018>
     0.000046 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0 \266\0\0\0\0\0\0"..., 832) = 832 <0.000013>
     0.000040 fstat(3, {st_mode=S_IFREG|0644, st_size=166488, ...}) = 0 <0.000013>
     0.000040 mmap(NULL, 168616, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f160b22a000 <0.000016>
     0.000041 mmap(0x7f160b235000, 81920, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xb000) = 0x7f160b235000 <0.000018>
     0.000044 mmap(0x7f160b249000, 36864, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1f000) = 0x7f160b249000 <0.000016>
     0.000040 mmap(0x7f160b252000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x27000) = 0x7f160b252000 <0.000015>
     0.000050 close(3)                  = 0 <0.000013>
     0.000042 openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3 <0.000017>
     0.000044 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0 \22\0\0\0\0\0\0"..., 832) = 832 <0.000014>
     0.000039 fstat(3, {st_mode=S_IFREG|0644, st_size=18816, ...}) = 0 <0.000013>
     0.000039 mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f160b228000 <0.000014>
     0.000043 mmap(NULL, 20752, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f160b222000 <0.000052>
     0.000080 mmap(0x7f160b223000, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1000) = 0x7f160b223000 <0.000037>
     0.000063 mmap(0x7f160b225000, 4096, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3000) = 0x7f160b225000 <0.000017>
     0.000042 mmap(0x7f160b226000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3000) = 0x7f160b226000 <0.000015>
     0.000049 close(3)                  = 0 <0.000013>
     0.000042 openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libSM.so.6", O_RDONLY|O_CLOEXEC) = 3 <0.000018>
     0.000046 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0p\"\0\0\0\0\0\0"..., 832) = 832 <0.000014>
     0.000047 fstat(3, {st_mode=S_IFREG|0644, st_size=39144, ...}) = 0 <0.000013>
     0.000039 mmap(NULL, 41320, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f160b217000 <0.000019>
     0.000043 mmap(0x7f160b219000, 20480, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7f160b219000 <0.000017>
     0.000043 mmap(0x7f160b21e000, 8192, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x7000) = 0x7f160b21e000 <0.000015>
     0.000040 mmap(0x7f160b220000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x8000) = 0x7f160b220000 <0.000014>
     0.000051 close(3)                  = 0 <0.000015>
     0.000037 openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libICE.so.6", O_RDONLY|O_CLOEXEC) = 3 <0.000015>
     0.000038 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0@Z\0\0\0\0\0\0"..., 832) = 832 <0.000010>
     0.000031 fstat(3, {st_mode=S_IFREG|0644, st_size=106176, ...}) = 0 <0.000009>
     0.000031 mmap(NULL, 122656, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f160b1f9000 <0.000011>
     0.000031 mmap(0x7f160b1fe000, 61440, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x5000) = 0x7f160b1fe000 <0.000014>
     0.000033 mmap(0x7f160b20d000, 20480, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x14000) = 0x7f160b20d000 <0.000011>
     0.000031 mmap(0x7f160b212000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x18000) = 0x7f160b212000 <0.000012>
     0.000035 mmap(0x7f160b214000, 12064, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f160b214000 <0.000011>
     0.000036 close(3)                  = 0 <0.000009>
     0.000054 openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libXau.so.6", O_RDONLY|O_CLOEXEC) = 3 <0.000015>
     0.000041 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`\23\0\0\0\0\0\0"..., 832) = 832 <0.000010>
     0.000032 fstat(3, {st_mode=S_IFREG|0644, st_size=18688, ...}) = 0 <0.000010>
     0.000031 mmap(NULL, 20744, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f160b1f3000 <0.000013>
     0.000032 mmap(0x7f160b1f4000, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1000) = 0x7f160b1f4000 <0.000015>
     0.000034 mmap(0x7f160b1f6000, 4096, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3000) = 0x7f160b1f6000 <0.000012>
     0.000031 mmap(0x7f160b1f7000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3000) = 0x7f160b1f7000 <0.000011>
     0.000040 close(3)                  = 0 <0.000009>
     0.000031 openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libXdmcp.so.6", O_RDONLY|O_CLOEXEC) = 3 <0.000013>
     0.000034 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240!\0\0\0\0\0\0"..., 832) = 832 <0.000010>
     0.000031 fstat(3, {st_mode=S_IFREG|0644, st_size=26800, ...}) = 0 <0.000009>
     0.000031 mmap(NULL, 28800, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f160b1eb000 <0.000012>
     0.000031 mmap(0x7f160b1ed000, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7f160b1ed000 <0.000014>
     0.000033 mmap(0x7f160b1ef000, 8192, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x4000) = 0x7f160b1ef000 <0.000012>
     0.000031 mmap(0x7f160b1f1000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x5000) = 0x7f160b1f1000 <0.000011>
     0.000041 close(3)                  = 0 <0.000009>
     0.000033 openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libuuid.so.1", O_RDONLY|O_CLOEXEC) = 3 <0.000013>
     0.000034 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200%\0\0\0\0\0\0"..., 832) = 832 <0.000010>
     0.000031 fstat(3, {st_mode=S_IFREG|0644, st_size=30936, ...}) = 0 <0.000009>
     0.000030 mmap(NULL, 32792, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f160b1e2000 <0.000012>
     0.000039 mmap(0x7f160b1e4000, 16384, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7f160b1e4000 <0.000392>
     0.000437 mmap(0x7f160b1e8000, 4096, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6000) = 0x7f160b1e8000 <0.000046>
     0.000123 mmap(0x7f160b1e9000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6000) = 0x7f160b1e9000 <0.000015>
     0.000106 close(3)                  = 0 <0.000009>
     0.000037 mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f160b1e0000 <0.000012>
     0.000038 openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libbsd.so.0", O_RDONLY|O_CLOEXEC) = 3 <0.000014>
     0.000038 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0@N\0\0\0\0\0\0"..., 832) = 832 <0.000010>
     0.000032 fstat(3, {st_mode=S_IFREG|0644, st_size=96728, ...}) = 0 <0.000010>
     0.000032 mmap(NULL, 102768, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f160b1c6000 <0.000012>
     0.000031 mprotect(0x7f160b1ca000, 77824, PROT_NONE) = 0 <0.000013>
     0.000031 mmap(0x7f160b1ca000, 61440, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x4000) = 0x7f160b1ca000 <0.000012>
     0.000031 mmap(0x7f160b1d9000, 12288, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x13000) = 0x7f160b1d9000 <0.000012>
     0.000030 mmap(0x7f160b1dd000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x16000) = 0x7f160b1dd000 <0.000012>
     0.000035 mmap(0x7f160b1df000, 368, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f160b1df000 <0.000011>
     0.000037 close(3)                  = 0 <0.000009>
     0.000049 mmap(NULL, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f160b1c3000 <0.000020>
     0.000093 arch_prctl(ARCH_SET_FS, 0x7f160b1c3780) = 0 <0.000010>
     0.000134 mprotect(0x7f160b6ba000, 12288, PROT_READ) = 0 <0.000027>
     0.000089 mprotect(0x7f160b1dd000, 4096, PROT_READ) = 0 <0.000015>
     0.000045 mprotect(0x7f160b1e9000, 4096, PROT_READ) = 0 <0.000014>
     0.000035 mprotect(0x7f160b1f1000, 4096, PROT_READ) = 0 <0.000013>
     0.000034 mprotect(0x7f160b1f7000, 4096, PROT_READ) = 0 <0.000013>
     0.000040 mprotect(0x7f160b212000, 4096, PROT_READ) = 0 <0.000013>
     0.000036 mprotect(0x7f160b220000, 4096, PROT_READ) = 0 <0.000013>
     0.000035 mprotect(0x7f160b226000, 4096, PROT_READ) = 0 <0.000014>
     0.000037 mprotect(0x7f160b252000, 4096, PROT_READ) = 0 <0.000014>
     0.000104 mprotect(0x7f160b7fc000, 4096, PROT_READ) = 0 <0.000017>
     0.000060 mprotect(0x7f160b267000, 4096, PROT_READ) = 0 <0.000014>
     0.000082 mprotect(0x7f160b4cb000, 4096, PROT_READ) = 0 <0.000013>
     0.000037 mprotect(0x7f160b81b000, 4096, PROT_READ) = 0 <0.000013>
     0.000046 mprotect(0x563a2374e000, 4096, PROT_READ) = 0 <0.000014>
     0.000593 mprotect(0x7f160b85b000, 4096, PROT_READ) = 0 <0.000029>
     0.000066 munmap(0x7f160b81f000, 60213) = 0 <0.000027>
     0.000426 brk(NULL)                 = 0x563a24c98000 <0.000075>
     0.000110 brk(0x563a24cb9000)       = 0x563a24cb9000 <0.000016>
     0.000158 openat(AT_FDCWD, "/usr/share/X11/locale/locale.alias", O_RDONLY) = 3 <0.000025>
     0.000065 fstat(3, {st_mode=S_IFREG|0644, st_size=83402, ...}) = 0 <0.000010>
     0.000038 read(3, "\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n"..., 4096) = 4096 <0.000011>
     0.000045 read(3, "UTF-8\nbo_IN.utf8\t\t\t\t\tbo_IN.UTF-8"..., 4096) = 4096 <0.000010>
     0.000040 read(3, "\t\t\tde_DE.ISO8859-15\nde_DE.88591\t"..., 4096) = 4096 <0.000010>
     0.000038 read(3, "9-1\nen_US.ISO-8859-1\t\t\t\ten_US.IS"..., 4096) = 4096 <0.000009>
     0.000044 read(3, "ISO8859-1\net_EE.ISO-8859-1\t\t\t\tet"..., 4096) = 4096 <0.000010>
     0.000039 read(3, "859-1\ngl_ES.iso885915\t\t\t\tgl_ES.I"..., 4096) = 4096 <0.000009>
     0.000038 read(3, "_KR.EUC\t\t\t\t\tko_KR.eucKR\nko_KR.EU"..., 4096) = 4096 <0.000010>
     0.000053 read(3, "88591\t\t\t\tnr_ZA.ISO8859-1\nnr_ZA.u"..., 4096) = 4096 <0.000010>
     0.000040 read(3, "sq_AL.ISO8859-2\nsq_AL.utf8\t\t\t\t\ts"..., 4096) = 4096 <0.000010>
     0.000039 read(3, "BE.ISO-8859-15@euro\t\t\t\twa_BE.ISO"..., 4096) = 4096 <0.000010>
     0.000040 read(3, "8859-1\t\t\t\t\ten_US.ISO8859-1\nISO-8"..., 4096) = 4096 <0.000010>
     0.000042 read(3, "BG.MICROSOFT-CP1251:\t\t\t\tbg_BG.CP"..., 4096) = 4096 <0.000010>
     0.000050 read(3, "-15\nde_BE.UTF-8@euro:\t\t\t\tde_BE.U"..., 4096) = 4096 <0.000010>
     0.000047 read(3, "N_US:\t\t\t\t\t\ten_US.ISO8859-1\nen_US"..., 4096) = 4096 <0.000010>
     0.000039 read(3, "\t\t\tes_US.ISO8859-1\nes_US.ISO-885"..., 4096) = 4096 <0.000010>
     0.000039 read(3, "859-1\nga_IE.ISO-8859-1:\t\t\t\tga_IE"..., 4096) = 4096 <0.000010>
     0.000050 read(3, "ISO-2022-JP:\t\t\t\tja_JP.JIS7\nja_JP"..., 4096) = 4096 <0.000010>
     0.000041 read(3, "9-1:\t\t\t\tnl_NL.ISO8859-1\nnl_NL.IS"..., 4096) = 4096 <0.000010>
     0.000040 read(3, "\tsd_IN.UTF-8\nsd@devanagari:\t\t\t\t\t"..., 4096) = 4096 <0.000018>
     0.000049 read(3, ".KOI8-U\nuk_UA:\t\t\t\t\t\tuk_UA.KOI8-U"..., 4096) = 4096 <0.000010>
     0.000041 read(3, ".iso88597:\t\t\t\t\tel_GR.ISO8859-7\nh"..., 4096) = 1482 <0.000010>
     0.000034 read(3, "", 4096)         = 0 <0.000015>
     0.000037 close(3)                  = 0 <0.000010>
     0.000032 openat(AT_FDCWD, "/usr/share/X11/locale/locale.dir", O_RDONLY) = 3 <0.000012>
     0.000035 fstat(3, {st_mode=S_IFREG|0644, st_size=40777, ...}) = 0 <0.000009>
     0.000044 read(3, "\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n"..., 4096) = 4096 <0.000010>
     0.000040 read(3, "8859-1/XLC_LOCALE\t\t\tes_CR.ISO885"..., 4096) = 4096 <0.000010>
     0.000037 read(3, "LC_LOCALE\t\t\tno_NO.ISO8859-15\niso"..., 4096) = 4096 <0.000009>
     0.000043 read(3, "s_IN.UTF-8\nen_US.UTF-8/XLC_LOCAL"..., 4096) = 4096 <0.000010>
     0.000037 read(3, "N.UTF-8@devanagari\nko_KR.UTF-8/X"..., 4096) = 4096 <0.000010>
     0.000037 close(3)                  = 0 <0.000009>
     0.000030 access("/usr/share/X11/locale/C/XLC_LOCALE", R_OK) = 0 <0.000009>
     0.000032 openat(AT_FDCWD, "/usr/share/X11/locale/C/XLC_LOCALE", O_RDONLY) = 3 <0.000011>
     0.000032 fstat(3, {st_mode=S_IFREG|0644, st_size=693, ...}) = 0 <0.000009>
     0.000036 read(3, "\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n"..., 4096) = 693 <0.000010>
     0.000057 read(3, "", 4096)         = 0 <0.000010>
     0.000029 close(3)                  = 0 <0.000009>
     0.000058 openat(AT_FDCWD, "/usr/share/X11/locale/locale.alias", O_RDONLY) = 3 <0.000015>
     0.000037 fstat(3, {st_mode=S_IFREG|0644, st_size=83402, ...}) = 0 <0.000009>
     0.000031 read(3, "\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n"..., 4096) = 4096 <0.000010>
     0.000098 read(3, "UTF-8\nbo_IN.utf8\t\t\t\t\tbo_IN.UTF-8"..., 4096) = 4096 <0.000029>
     0.000062 read(3, "\t\t\tde_DE.ISO8859-15\nde_DE.88591\t"..., 4096) = 4096 <0.000010>
     0.000042 read(3, "9-1\nen_US.ISO-8859-1\t\t\t\ten_US.IS"..., 4096) = 4096 <0.000010>
     0.000039 read(3, "ISO8859-1\net_EE.ISO-8859-1\t\t\t\tet"..., 4096) = 4096 <0.000010>
     0.000039 read(3, "859-1\ngl_ES.iso885915\t\t\t\tgl_ES.I"..., 4096) = 4096 <0.000010>
     0.000051 read(3, "_KR.EUC\t\t\t\t\tko_KR.eucKR\nko_KR.EU"..., 4096) = 4096 <0.000010>
     0.000040 read(3, "88591\t\t\t\tnr_ZA.ISO8859-1\nnr_ZA.u"..., 4096) = 4096 <0.000010>
     0.000039 read(3, "sq_AL.ISO8859-2\nsq_AL.utf8\t\t\t\t\ts"..., 4096) = 4096 <0.000010>
     0.000041 read(3, "BE.ISO-8859-15@euro\t\t\t\twa_BE.ISO"..., 4096) = 4096 <0.000010>
     0.000040 read(3, "8859-1\t\t\t\t\ten_US.ISO8859-1\nISO-8"..., 4096) = 4096 <0.000010>
     0.000041 read(3, "BG.MICROSOFT-CP1251:\t\t\t\tbg_BG.CP"..., 4096) = 4096 <0.000010>
     0.000041 read(3, "-15\nde_BE.UTF-8@euro:\t\t\t\tde_BE.U"..., 4096) = 4096 <0.000010>
     0.000040 read(3, "N_US:\t\t\t\t\t\ten_US.ISO8859-1\nen_US"..., 4096) = 4096 <0.000010>
     0.000039 read(3, "\t\t\tes_US.ISO8859-1\nes_US.ISO-885"..., 4096) = 4096 <0.000010>
     0.000043 read(3, "859-1\nga_IE.ISO-8859-1:\t\t\t\tga_IE"..., 4096) = 4096 <0.000010>
     0.000040 read(3, "ISO-2022-JP:\t\t\t\tja_JP.JIS7\nja_JP"..., 4096) = 4096 <0.000010>
     0.000041 read(3, "9-1:\t\t\t\tnl_NL.ISO8859-1\nnl_NL.IS"..., 4096) = 4096 <0.000010>
     0.000043 read(3, "\tsd_IN.UTF-8\nsd@devanagari:\t\t\t\t\t"..., 4096) = 4096 <0.000010>
     0.000041 read(3, ".KOI8-U\nuk_UA:\t\t\t\t\t\tuk_UA.KOI8-U"..., 4096) = 4096 <0.000010>
     0.000047 read(3, ".iso88597:\t\t\t\t\tel_GR.ISO8859-7\nh"..., 4096) = 1482 <0.000010>
     0.000036 read(3, "", 4096)         = 0 <0.000010>
     0.000030 close(3)                  = 0 <0.000010>
     0.000030 openat(AT_FDCWD, "/usr/share/X11/locale/locale.dir", O_RDONLY) = 3 <0.000012>
     0.000034 fstat(3, {st_mode=S_IFREG|0644, st_size=40777, ...}) = 0 <0.000010>
     0.000047 read(3, "\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n"..., 4096) = 4096 <0.000010>
     0.000041 read(3, "8859-1/XLC_LOCALE\t\t\tes_CR.ISO885"..., 4096) = 4096 <0.000010>
     0.000038 read(3, "LC_LOCALE\t\t\tno_NO.ISO8859-15\niso"..., 4096) = 4096 <0.000010>
     0.000046 read(3, "s_IN.UTF-8\nen_US.UTF-8/XLC_LOCAL"..., 4096) = 4096 <0.000010>
     0.000038 read(3, "N.UTF-8@devanagari\nko_KR.UTF-8/X"..., 4096) = 4096 <0.000010>
     0.000038 close(3)                  = 0 <0.000032>
     0.000054 access("/usr/share/X11/locale/C/XLC_LOCALE", R_OK) = 0 <0.000012>
     0.000034 openat(AT_FDCWD, "/usr/share/X11/locale/C/XLC_LOCALE", O_RDONLY) = 3 <0.000011>
     0.000032 fstat(3, {st_mode=S_IFREG|0644, st_size=693, ...}) = 0 <0.000009>
     0.000036 read(3, "\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n"..., 4096) = 693 <0.000010>
     0.000053 read(3, "", 4096)         = 0 <0.000009>
     0.000029 close(3)                  = 0 <0.000010>
     0.000066 socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC, 0) = 3 <0.000019>
     0.000040 connect(3, {sa_family=AF_UNIX, sun_path=@"/tmp/.X11-unix/X0"}, 20) = 0 <0.000020>
     0.000043 getpeername(3, {sa_family=AF_UNIX, sun_path=@"/tmp/.X11-unix/X0"}, [124->20]) = 0 <0.000010>
     0.000047 uname({sysname="Linux", nodename="ubuntu-Standard-PC-Q35-ICH9-2009", ...}) = 0 <0.000010>
     0.000058 access("/run/user/1000/gdm/Xauthority", R_OK) = 0 <0.000023>
     0.000063 openat(AT_FDCWD, "/run/user/1000/gdm/Xauthority", O_RDONLY) = 4 <0.000012>
     0.000033 fstat(4, {st_mode=S_IFREG|0700, st_size=152, ...}) = 0 <0.000010>
     0.000034 read(4, "\1\0\0 ubuntu-Standard-PC-Q35-ICH9-"..., 4096) = 152 <0.000024>
     0.000049 read(4, "", 4096)         = 0 <0.000009>
     0.000029 close(4)                  = 0 <0.000010>
     0.000029 getsockname(3, {sa_family=AF_UNIX}, [124->2]) = 0 <0.000010>
     0.000043 fcntl(3, F_GETFL)         = 0x2 (flags O_RDWR) <0.000009>
     0.000030 fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0 <0.000009>
     0.000028 fcntl(3, F_SETFD, FD_CLOEXEC) = 0 <0.000009>
     0.000031 poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}]) <0.000010>
     0.000045 writev(3, [{iov_base="l\0\v\0\0\0\22\0\20\0\0\0", iov_len=12}, {iov_base="", iov_len=0}, {iov_base="MIT-MAGIC-COOKIE-1", iov_len=18}, {iov_base="\0\0", iov_len=2}, {iov_base="\222@\343@\340*4\250\202Z\0\3\323\345\220y", iov_len=16}, {iov_base="", iov_len=0}], 6) = 48 <0.000018>
     0.000055 recvfrom(3, 0x563a24ca0730, 8, 0, NULL, NULL) = -1 EAGAIN (Resource temporarily unavailable) <0.000010>
     0.000036 poll([{fd=3, events=POLLIN}], 1, -1) = 1 ([{fd=3, revents=POLLIN}]) <0.000010>
     0.000034 recvfrom(3, "\1\0\v\0\0\0\207\6", 8, 0, NULL, NULL) = 8 <0.000011>
     0.000051 recvfrom(3, "X6\267\0\0\0\200\2\377\377\37\0\0\1\0\0\24\0\377\377\1\7\0\0  \10\377\0\0\0\0"..., 6684, 0, NULL, NULL) = 6684 <0.000013>
     0.000071 poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}]) <0.000010>
     0.000034 writev(3, [{iov_base="b\0\5\0\f\0\0\0BIG-REQUESTS", iov_len=20}], 1) = 20 <0.000014>
     0.000037 poll([{fd=3, events=POLLIN}], 1, -1) = 1 ([{fd=3, revents=POLLIN}]) <0.000046>
     0.000070 recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\1\0\1\0\0\0\0\0\1\205\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 32 <0.000011>
     0.000040 poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}]) <0.000009>
     0.000032 writev(3, [{iov_base="\205\0\1\0", iov_len=4}], 1) = 4 <0.000022>
     0.000045 poll([{fd=3, events=POLLIN}], 1, -1) = 1 ([{fd=3, revents=POLLIN}]) <0.000031>
     0.000059 recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\1\0\2\0\0\0\0\0\377\377?\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 32 <0.000010>
     0.000044 recvmsg(3, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable) <0.000010>
     0.000035 poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}]) <0.000009>
     0.000032 writev(3, [{iov_base="7\0\5\0\0\0\200\2\264\3\0\0\10\0\0\0\377\377\377\0\24\0\6\0\264\3\0\0\27\0\0\0"..., iov_len=44}, {iov_base=NULL, iov_len=0}, {iov_base="", iov_len=0}], 3) = 44 <0.000013>
     0.000040 poll([{fd=3, events=POLLIN}], 1, -1) = 1 ([{fd=3, revents=POLLIN}]) <0.000043>
     0.000074 recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\1\10\4\0$\0\0\0\37\0\0\0\0\0\0\0\220\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 176 <0.000011>
     0.000045 poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}]) <0.000017>
     0.000041 writev(3, [{iov_base="b\0\5\0\t\0\200\2", iov_len=8}, {iov_base="XKEYBOARD", iov_len=9}, {iov_base="\0\0\0", iov_len=3}], 3) = 20 <0.000014>
     0.000041 poll([{fd=3, events=POLLIN}], 1, -1) = 1 ([{fd=3, revents=POLLIN}]) <0.000046>
     0.000076 recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\1\0\5\0\0\0\0\0\1\207U\211\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 32 <0.000010>
     0.000037 poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}]) <0.000010>
     0.000032 writev(3, [{iov_base="\207\0\2\0\1\0\0\0", iov_len=8}, {iov_base=NULL, iov_len=0}, {iov_base="", iov_len=0}], 3) = 8 <0.000013>
     0.000041 poll([{fd=3, events=POLLIN}], 1, -1) = 1 ([{fd=3, revents=POLLIN}]) <0.000040>
     0.000063 recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\1\1\6\0\0\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 32 <0.000010>
     0.000046 poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}]) <0.000017>
     0.000040 writev(3, [{iov_base="\20\0\5\0\t\0\0\0CLIPBOARD\377\377\0", iov_len=20}, {iov_base=NULL, iov_len=0}, {iov_base="", iov_len=0}], 3) = 20 <0.000013>
     0.000038 poll([{fd=3, events=POLLIN}], 1, -1) = 1 ([{fd=3, revents=POLLIN}]) <0.000029>
     0.000065 recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\1\0\7\0\0\0\0\0\323\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 32 <0.000010>
     0.000039 poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}]) <0.000010>
     0.000032 writev(3, [{iov_base="\20\0\5\0\v\0\0\0UTF8_STRING\0", iov_len=20}, {iov_base=NULL, iov_len=0}, {iov_base="", iov_len=0}], 3) = 20 <0.000012>
     0.000037 poll([{fd=3, events=POLLIN}], 1, -1) = 1 ([{fd=3, revents=POLLIN}]) <0.000010>
     0.000040 recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\1\0\10\0\0\0\0\0\34\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 32 <0.000010>
     0.000037 poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}]) <0.000010>
     0.000032 writev(3, [{iov_base="\1\0\n\0\1\0\200\2\264\3\0\0\0\0\0\0\1\0\1\0\0\0\0\0\0\0\0\0\n\0\0\0"..., iov_len=76}, {iov_base=NULL, iov_len=0}, {iov_base="", iov_len=0}], 3) = 76 <0.000017>
     0.000042 poll([{fd=3, events=POLLIN}], 1, -1) = 1 ([{fd=3, revents=POLLIN}]) <0.000020>
     0.000190 recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\1\0\v\0\0\0\0\0\21\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 32 <0.000030>
     0.000102 poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}]) <0.000010>
     0.000034 writev(3, [{iov_base="\20\0\3\0\4\0\200\2INCR", iov_len=12}, {iov_base=NULL, iov_len=0}, {iov_base="", iov_len=0}], 3) = 12 <0.000018>
     0.000050 poll([{fd=3, events=POLLIN}], 1, -1) = 1 ([{fd=3, revents=POLLIN}]) <0.000041>
     0.000065 recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\1\0\f\0\0\0\0\0\362\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 32 <0.000010>
     0.000049 poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}]) <0.000010>
     0.000034 writev(3, [{iov_base="\30\0\6\0\1\0\200\2\323\1\0\0\34\1\0\0\21\2\0\0\0\0\0\0", iov_len=24}, {iov_base=NULL, iov_len=0}, {iov_base="", iov_len=0}], 3) = 24 <0.000013>
     0.000040 poll([{fd=3, events=POLLIN}], 1, -1) = ? ERESTART_RESTARTBLOCK (Interrupted by signal) <2.770843>
strace: Process 12862 detached

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2020-04-15:

#5

hanging-clipboard-20.04.ogv Edit (3.6 MiB, video/ogg)

Here is an example,
- on the bottom you see keys pressed (all arrive int he guest)
- on the right you see xclip looped as shown in comment #2
- on the left you see the editor

I add a few lines of text in the editor to explain what is going on.

@John - does that somewhat match what you are seeing?

@Desktop-team - any idea what might be going on?

Changed in virt-manager (Ubuntu):
status:	New → Invalid
summary:	- Clipboard doesn't work 100% of the time in Ubuntu 20.04 with virt- - manager + Clipboard doesn't work 100% of the time in Ubuntu 20.04 (in KVM guests)

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2020-04-15:

#6

@Desktop Team:
For its similarity with bug 1852183 I'll start with `mutter`, but please re-triage this to where you think this really belongs.

tags:

added: champagne

Revision history for this message

John Morrison (johnmorrison) wrote on 2020-04-15:

#7

Hi Christian,

> I found some odd behavior, sometimes it would seem as if my copy would not work.
> Pasting then would paste "nothing" later on if I copy something again it would "free up" and unblock all old calls, suddenly pasting all of them.
>
> Example
> text editor with:
> aa
> bb
> cc
> Then I copy "aa" but the system locks up.
> I go to the next line and try to paste it three times (nothing happens).
> Then I copy "bb" which "unblocks" the system.
> The three times "aa" paste now appear at once.

This is exactly is the problem. And it's happening both in guest and the host when the virt-manager window is opened. You can notice that very soon when you keep a virt-manager window opened and start for example coding in the host. After a few Ctrl+x / Ctrl+v you realize that your clipboard is broken and you need to close virt-manager (workaround is to close virt-manager but then you can't use the VM...).

I didn't notice the problem in Ubuntu 20.04 (GNOME) as host. At this moment I'm running Kubuntu 20.04 (KDE Plasma) as the host and I'm noticing the clipboard issues with both Kubuntu (Plasma) and Ubuntu (GNOME) guests.

@Christian: Thank you very much Christian for triaging and testing ;-).

@Desktop: Big shout-out to your team and to the new team lead @Wimpy. Please let me know if you have any questions ;-). Thank you!

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2020-04-15:

#8

I can't recreate this on a 20.04 host neither with virt-manager open or not.
Only in the guest.
I tried editor (gnome) and kate (KDE editor) on y gnome based 20.04.

Very awkward issue, I hope my video helps and I'm looking forward to what Desktop people say as well.

Revision history for this message

John Morrison (johnmorrison) wrote on 2020-04-15:

#9

Hi Christian,

Thank you. Did you try it on Ubuntu or Kubuntu host?

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2020-04-15: Re: [Bug 1872527] Re: Clipboard doesn't work 100% of the time in Ubuntu 20.04 (in KVM guests)

#10

> Thank you. Did you try it on Ubuntu or Kubuntu host?

Host was Ubuntu

Revision history for this message

John Morrison (johnmorrison) wrote on 2020-04-15:

#11

In my case (with Kubuntu 20.04) I can't even have the virt-manager window opened since it's messing up with the host clipboard (KDE Plasma clipboard). I need to close the virt-manager or I need to open a VM with no desktop (a server without X is fine).

In other words:
1. host Kubuntu with guest Ubuntu: problem both within guest and host
2. host Kubuntu with guest Kubuntu: problem both within guest and host
3. host Kubuntu with guest with no X - OK

Thank you.

Revision history for this message

Bryce Harrington (bryce) wrote on 2020-04-15:

#12

It sort of sounds like there is a race condition going on in the consumption of the key sequence. I don't want to guess exactly what the problem is in this particular case, but just as general X info (which you probably already know...):

Keyboard input is processed through several levels... hardware, kernel, X server, input manager, window manager, and applications. And virtualization adds another layer in there too. Each layer does some translation, such as from hardware key events into key id's, id's translated into language-specific key symbols, key symbols like [ctrl, v] into key combos/sequences like ^v, sequences into commands like "paste", etc. At any of these layers, an input event can be "consumed", making it not available to other things later in the layers.

Comment #2 in particular seems to do a good job of narrowing where the issue occurs. Using screenkey to verify the key events are reaching the guest rules out hardware layer through virtualization. Reproducing the bug in GNOME as well as KDE seems to rule out window manager. So... my guess would be to look at what applications (or services) might also be trying to consume the key sequence.

GNOME (and KDE) coordinate the key handling by applications, so that would be a first thing to check. Is it also possible there is a non-GTK/non-Qt service, process, or app that is skipping that (X can be a bit overly permissive...)

A couple tools that can be useful for probing/debugging keyboard handling issues are `xev` and `xdotool`. The former shows you debug information as you hit keys, the latter lets you synthetically create them. For example:

xdotool mousedown --clearmodifiers 2
xdotool mouseup 2
xdotool keyup alt
xdotool keyup ctrl
xdotool keyup shift

xev should be pretty self explanatory.

On a different note... You probably already know about Linux's primary and secondary clipboards. Sometimes confusion derives from things getting copied to the other clipboard than intended, which can be tested. Other times it seems some app gets a lock on one clipboard or puts it into some sort of mode so nothing can copy into it; you may run into this with firefox or other non-GNOME/non-KDE apps used in a GNOME or KDE environment.

So, see if you can rule out whether the problem can be localized to the handling of the key events, or if it is specific to the copying, or the pasting behavior. And examine what processes are running, and in particular note any non-KDE/non-GNOME things that may be inserting themselves.

It sort of sounds like there is a race condition going on in the consumption of the key sequence.  I don't want to guess exactly what the problem is in this particular case, but just as general X info (which you probably already know...):

Keyboard input is processed through several levels... hardware, kernel, X server, input manager, window manager, and applications.  And virtualization adds another layer in there too.  Each layer does some translation, such as from hardware key events into key id's, id's translated into language-specific key symbols, key symbols like [ctrl, v] into key combos/sequences like ^v, sequences into commands like "paste", etc.  At any of these layers, an input event can be "consumed", making it not available to other things later in the layers.

Comment #2 in particular seems to do a good job of narrowing where the issue occurs.  Using screenkey to verify the key events are reaching the guest rules out hardware layer through virtualization.  Reproducing the bug in GNOME as well as KDE seems to rule out window manager.  So...  my guess would be to look at what applications (or services) might also be trying to consume the key sequence.

GNOME (and KDE) coordinate the key handling by applications, so that would be a first thing to check.  Is it also possible there is a non-GTK/non-Qt service, process, or app that is skipping that (X can be a bit overly permissive...)

A couple tools that can be useful for probing/debugging keyboard handling issues are `xev` and `xdotool`.  The former shows you debug information as you hit keys, the latter lets you synthetically create them.  For example:

xdotool mousedown --clearmodifiers 2
xdotool mouseup 2
xdotool keyup alt
xdotool keyup ctrl
xdotool keyup shift

xev should be pretty self explanatory.

On a different note...  You probably already know about Linux's primary and secondary clipboards.  Sometimes confusion derives from things getting copied to the other clipboard than intended, which can be tested.  Other times it seems some app gets a lock on one clipboard or puts it into some sort of mode so nothing can copy into it; you may run into this with firefox or other non-GNOME/non-KDE apps used in a GNOME or KDE environment.

So, see if you can rule out whether the problem can be localized to the handling of the key events, or if it is specific to the copying, or the pasting behavior.  And examine what processes are running, and in particular note any non-KDE/non-GNOME things that may be inserting themselves.

Revision history for this message

John Morrison (johnmorrison) wrote on 2020-04-16:

#13

Hi Bryce,

After long testing I have no problems with any key shortcuts (Ctrl+d and Ctrl+z for example), I only see this issue when using Clipboard.

I tested:
Kubuntu host with Console (Qt terminal) and Ubuntu guest with GNOME terminal (GTK) - problem
Kubuntu host with Console (Qt terminal) and Kubuntu guest with Console (Qt terminal) - problem
Kubuntu host with Kate (Qt text editor) and Ubuntu guest with GNOME text editor (GTK) - problem
Kubuntu host with Kate (Qt text editor) and Kubuntu guest with Kate (Qt text editor) - problem

All after a fresh reboot - no other applications running, no extensions in GNOME.

ALL shortcuts work (Ctrl+d, Ctrl+z..., Shift+Ctrl+z...), the only problem is Clipboard shortcuts and pasting / copying using mouse.

That tells me that the problem is clipboard, not the input (mouse / keyboard).

Please let me know if you need more info ;-). Thank you!

(btw. I almost lost this post since I Ctrl+x it from Kate and then I wasn't able to Paste it using Ctrl+v or by mouse, good thing is that I didn't close the Kate so I just Ctrl+z and I copied it again ;-))

Revision history for this message

Launchpad Janitor (janitor) wrote on 2020-04-17:

#14

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

Changed in mutter (Ubuntu):
status:	New → Confirmed

Revision history for this message

Daniel van Vugt (vanvugt) wrote on 2020-04-20:

#15

There's a surprising number of clipboard fixes already landed upstream and waiting to be released in mutter 3.36.2 -- we should probably wait and see if they help. Most of them don't have associated bug reports :/

Also, in case you haven't already please try both 'Ubuntu' and 'Ubuntu on Wayland'. In case one works better than the other. It looks like some upstream fixes are specific to one or the other.

Revision history for this message

John Morrison (johnmorrison) wrote on 2020-04-20:

#16

Hi Daniel,

Thank you.

Btw. is Mutter also in Kubuntu (KDE Plasma)? The reason I'm asking is that this issue is not just happening between Ubuntu host and Ubuntu guest (more details above). This is also happening between Kubuntu host and Kubuntu guest.

If there is no mutter in Kubuntu then this bug can't be in Mutter.

Thank you.

Revision history for this message

Daniel van Vugt (vanvugt) wrote on 2020-04-21:

#17

No mutter is not used in Kubuntu as far as I know.

I was wondering about that. If you can reproduce the bug without Mutter being involved then obviously it shouldn't be assigned to Mutter. I will shotgun a few related projects... They might not all be to blame but at least other people will be able to find the bug and avoid logging duplicates.

Changed in virt-manager (Ubuntu):
status:	Invalid → Confirmed
Changed in qemu (Ubuntu):
status:	New → Confirmed
Changed in qemu-kvm (Ubuntu):
status:	New → Confirmed
no longer affects:	mutter (Ubuntu)
no longer affects:	qemu-kvm (Ubuntu)

Revision history for this message

Daniel van Vugt (vanvugt) wrote on 2020-04-22:

#18

In case anyone lands on the wrong bug, as often happens, please see also bug 1852183.

Changed in spice (Ubuntu):
status:	New → Confirmed

Revision history for this message

w (lwk32) wrote on 2020-05-09:

#19

I have issues with copy and pasting on KVM too. In fact, it freezes the IDEs (vs code/intellij) when i tried to copy and paste. Sometimes it cause vs code to crash too.

After searching around, I found another person who has the exact same issues albeit on Red Hat:
https://bugzilla.redhat.com/show_bug.cgi?id=1600798

I tried disabling copy paste on spice-vdagent via virt as suggested in the link, and I no longer have any freezing issues.

Seems like there's a bug with spice-vdagent. Do let me know if i should create a separate issue for this.

Daniel van Vugt (vanvugt) on 2020-05-11

description:

updated

Revision history for this message

w (lwk32) wrote on 2020-05-13:

#20

update - after manually building and installing spice-vdagent 0.20 from Groovy, spice's clipboard works as expected.

I no longer need to disable clipboard on virt manager to resolve the copy and paste issues.

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2020-05-13:

#21

Since Daniel split up the "related but not the same" mutter changes to bug 1852183 (thanks for that work BTW!) let us here focus on the spice component.

Thanks lwk32 for identifying a fix for that, I'll be taking a look if that is SRU-safely backportable to Focal.

Changed in virt-manager (Ubuntu):
status:	Confirmed → Invalid
Changed in spice (Ubuntu):
status:	Confirmed → Invalid
Changed in qemu (Ubuntu):
status:	Confirmed → Invalid
no longer affects:	spice (Ubuntu Focal)
no longer affects:	qemu (Ubuntu Focal)
no longer affects:	virt-manager (Ubuntu Focal)
Changed in spice-vdagent (Ubuntu):
status:	New → Fix Released
Changed in spice-vdagent (Ubuntu Focal):
status:	New → Triaged

Bug Watch Updater (bug-watch-updater) on 2020-05-13

Changed in spice-vdagent (Debian):
status:	Unknown → Fix Released

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2020-05-13:

#22

There are plenty of components involved in "trying" to fix this by spice upstream.
The discussion in
https://gitlab.freedesktop.org/spice/linux/vd_agent/-/issues/9
is rather long.
It eventually seems to be fixed in
https://gitlab.freedesktop.org/spice/linux/vd_agent/-/merge_requests/4
I think we have all components in place, except the spice-vdagent 0.20 and maybe spice-protocol 14.1.

The series of fixes for spcie-vdagent linked there would be:
  e0bfa67 configure: bump gtk+ >= 3.22
  2c72378 clipboard: remove vdagent-selection-id usage
  79d0125 configure: depend on gobject
  ff30f58 configure: bump gobject >= 2.50
  fb69a49 vdagent: use G_OPTION_FLAG_NONE
  aa26d1d clipboard: gobject-ify VDAgentClipboards
  2ad6c15 clipboard: filter out only our own events
  c9e8067 clipboard: only send release when no immediate grab
  a2fc33c clipboard: implement CAP_CLIPBOARD_GRAB_SERIAL
From https://gitlab.freedesktop.org/spice/linux/vd_agent.git

Our libglib2.0-dev and libgtk-3-dev are new enough as well.
But spice-protocol needs:
045a6978 vdagent: introduce VD_AGENT_CAP_CLIPBOARD_GRAB_SERIAL
4f397d69 vdagent: introduce VD_AGENT_CAP_CLIPBOARD_NO_RELEASE_ON_REGRAB
That is in 0.14.1 which only is in Ubuntu 20.10 already, but not in Focal (14.0 there).

I'd expect that 0.20 would not even build without spice-protocol 0.14.1 since the definition of VD_AGENT_CAP_CLIPBOARD_GRAB_SERIAL is missing. Well it might skip it safely.
But the report of lwk32 says building 0.20 is fixing his issue, so let us give it a try.

We cant take:
a2fc33c clipboard: implement CAP_CLIPBOARD_GRAB_SERIAL
c9e8067 clipboard: only send release when no immediate grab
without this change to spice-protocol which is hard to SRU. The rest of the patches applies cleanly, but I'm unsure if there can be any gain without these final commits.

@lwk32 would you mind giving the PPA [1] a try with an otherwise unmodified Ubuntu 20.04 if that fixes the issue for you as well?

P.S. We might want to wait until the more clear fix in bug 1852183 lands to not mix results of verifications of -proposed - but we can sniff things right now based on the PPA.

[1]: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4060

There are plenty of components involved in "trying" to fix this by spice upstream.
The discussion in
  https://gitlab.freedesktop.org/spice/linux/vd_agent/-/issues/9
is rather long.
It eventually seems to be fixed in
  https://gitlab.freedesktop.org/spice/linux/vd_agent/-/merge_requests/4
I think we have all components in place, except the spice-vdagent 0.20 and maybe spice-protocol 14.1.

The series of fixes for spcie-vdagent linked there would be:
  e0bfa67 configure: bump gtk+ >= 3.22
  2c72378 clipboard: remove vdagent-selection-id usage
  79d0125 configure: depend on gobject
  ff30f58 configure: bump gobject >= 2.50
  fb69a49 vdagent: use G_OPTION_FLAG_NONE
  aa26d1d clipboard: gobject-ify VDAgentClipboards
  2ad6c15 clipboard: filter out only our own events
  c9e8067 clipboard: only send release when no immediate grab
  a2fc33c clipboard: implement CAP_CLIPBOARD_GRAB_SERIAL
From https://gitlab.freedesktop.org/spice/linux/vd_agent.git

Our libglib2.0-dev and libgtk-3-dev are new enough as well.
But spice-protocol needs:
045a6978 vdagent: introduce VD_AGENT_CAP_CLIPBOARD_GRAB_SERIAL
4f397d69 vdagent: introduce VD_AGENT_CAP_CLIPBOARD_NO_RELEASE_ON_REGRAB
That is in 0.14.1 which only is in Ubuntu 20.10 already, but not in Focal (14.0 there).

I'd expect that 0.20 would not even build without spice-protocol 0.14.1 since the definition of VD_AGENT_CAP_CLIPBOARD_GRAB_SERIAL is missing. Well it might skip it safely.
But the report of lwk32 says building 0.20 is fixing his issue, so let us give it a try.

We cant take:
  a2fc33c clipboard: implement CAP_CLIPBOARD_GRAB_SERIAL
  c9e8067 clipboard: only send release when no immediate grab
without this change to spice-protocol which is hard to SRU. The rest of the patches applies cleanly, but I'm unsure if there can be any gain without these final commits.

@lwk32 would you mind giving the PPA [1] a try with an otherwise unmodified Ubuntu 20.04 if that fixes the issue for you as well?

P.S. We might want to wait until the more clear fix in bug 1852183 lands to not mix results of verifications of -proposed - but we can sniff things right now based on the PPA.

[1]: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4060

Changed in spice-protocol (Ubuntu):
status:	New → Fix Released
Changed in spice-protocol (Ubuntu Focal):
status:	New → Incomplete

Revision history for this message

w (lwk32) wrote on 2020-05-14:

#23

You are right. I need to build spice-protocol 0.14.1 to get spice-vdagent 0.20 to work.

Revision history for this message

w (lwk32) wrote on 2020-05-14:

#24

I don't mind trying out the ppa, but my distro is Pop OS Ubuntu 20.04. Is that alright?

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2020-05-14:

#25

@lwk32 - If you remove your self-built spice-vdagent and spice protocol and reset reset spice* to the versions from (your) archive that should be fine.

You then should be able to run with spice-vdagent 0.19.0-2ubuntu0.1~ppa2 from the PPA.

My assumption is that this won't be enough missing the last two changes, but it is worth a try.
Please report if it works for you with that build and if it does an output of `dpkg -l` so that I can make sure the relevant components installed are the expected versions.

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2020-05-14:

#26

a list of current virt components in Ubuntu 20.04 for comparison Edit (6.3 KiB, text/plain)

Revision history for this message

w (lwk32) wrote on 2020-05-14:

#27

ok let me try. I tried to upgrade another VM from 18.04 to 20.04 to do this, but I didn't experience any copy and paste issues by doing so.

The affected VM was from 19.10 to 20.04. I will test the VM out with your suggestions

Revision history for this message

w (lwk32) wrote on 2020-05-14:

#28

dpkg status of Ubuntu 20.04 after applying ppa2 fix Edit (134 bytes, text/plain)

Ok so I'm attaching the dpkg -l output after my tests. I found no obvious issues with the fix in ppa2.

I also tested the ppa2 on a freshly installed Ubuntu 20.04 and found no obvious issues. The team might want to consider deploying this fix and see if it could help more users and get their feedback.

Note that I was testing the 'guest' VMs as I was having issues with them all along.

guest-ubuntu.txt is from a freshly installed Ubuntu 20.04 VM

guest-after.txt is from the original affected VM with Pop OS 20.04 installed.

Revision history for this message

w (lwk32) wrote on 2020-05-14:

#29

guest-after.txt Edit (438 bytes, text/plain)

this is guest-after.txt

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2020-05-15:

#30

Thanks, the versions in the guest should be good then.
So does it work and fix the bug?

Unfortunately just knowing that it "works" isn't enough it should be relibaly switching between buggy and good state when changing the package versions (and reboot the guest).
Otherwise we might just look at something that is - in addition to the issue - flaky.

Let me know once you have tried that in detail and got your feedback from the wider test with the team.

We still need to bring up step-by-step test instructions then to be able to verify this in the SRU process. So if in your testing anything in particular turns out to be the most reliable way to see the issue let me know.

Revision history for this message

w (lwk32) wrote on 2020-05-18:

#31

Unfortunately, I wasn't able to re-enact the buggy state when I uninstalled the packages. Not sure why.

I even tried to upgrade a clean version of Ubuntu 19.10 and 20.04 and still can't get the buggy state with that version.

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2020-05-18:

#32

We know (from the commits) that it is a race - maybe the race window is actually rather small and only few people run into it (and rarely).

Having it fixed in 20.10 is already a good thing.
But the SRU of a fix will need some sort of reproducer, especially with this somewhat more complex change and the consideration of only partial backports :-/

@w - if you happen to trigger it reliably again let me know
@anyone affected finding this please speak up how you reliably trigger it so we can go on.

Changed in spice-vdagent (Ubuntu Focal):
status:	Triaged → Incomplete

Revision history for this message

Stan (cruisevx1) wrote on 2020-05-20:

#33

A general userland comment:

Reading the above, I experience this among Centos VMs. It is very hard to reproduce for typical text copy/pastes involving bash terminals, text files, and spreadsheets (libre).

However, it plagues me for copying from Firefox web pages. It is so bad that I often open up a simple text file on the copy-from VM to see if anything is being captured. In those cases, the paste usually does not paste anything.

I realize that this is not a bug report, but maybe this scenario will help create a context for further debugging, that may provide a higher repro rate.

This bug is very worth fixing.

Revision history for this message

Stan (cruisevx1) wrote on 2020-05-20:

#34

Actually another scenario which is even worse now that I have experienced again today, is copy/paste is broken within libreoffice, on a VM. It gets to the point libreoffice hangs completely, and then the VM itself. Eventually the VM logs me right off. Logging back on, and launching libreoffice, all is well.
In this scenario, best to have done prior saves in libreoffice. Never do the doc recovery.

I believe this broken scenario is actually triggered by having tried to do copy/pastes from firefox on another VM to this VM. After this the instance on libreoffice is somewhat broken, progressing to the hang.
Nasty.

Revision history for this message

Jules Samuel Randolph (jsamr) wrote on 2020-05-23:

#35

I have experienced the same inconsistencies as reported by OP between Ubuntu
20.04 guest and hosts. The guest is connected through SPICE. On top of that,
the clipboard has been working unreliably within the host system (i3). For
example, I often have to copy multiple times the same text to have it enter
the system clipboard. Moreover, calls to clipboard with CTRL+V can take a
few seconds. When the guest is powered off, the issue does not resurface. I
have tried to reproduce the issue with Debian 10 and other guests, with
no “luck”.

Revision history for this message

Kevin (swiftninja) wrote on 2020-05-24:

#36

Just chiming in to say that I am experiencing this problem on a fresh install of Kubuntu 20.04. I previously experienced it on a forced upgrade from 19.10->20.04; I thought perhaps the upgrade process was too premature so I wiped and started fresh. Still broken. Sometimes it works, sometimes it doesn't. I find I often have to hit CTRL+C twice to get it to work.

My observations are that the clipboard manager actually has the contents I'm looking for. It just sometimes refuses to paste them. It doesn't seem to be a keyboard issue, because I can press CTRL+C, CTRL+V, and the paste wont work no matter how many times I press CTRL+V. But if I open the clipboard manager in the tray, I can see clearly that it "copied" the value I wanted into the clipboard. If I then select that value using the GUI, suddenly CTRL+V will now paste the item.

So, FWIW, it may not be anything to do with keyboard race conditions so much as a core fundamental problem with the clipboard manager. I did not have these problems with 18.04, 19.04, or 19.10, and my hardware has not changed between versions.

Also want to note that I'm also having strange selection behavior in GTK+ apps. Selections won't hold most of the time - I'll select the text, and the second I let go of the SHIFT key, the selection disappears. Very, very frustrating.

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2020-05-25:

#37

Since bug 1852183 is released this is fixed for many but not all cases.
More people chime in to be affected and there seems to be a spike of KDE users in that (which makes sense as they won't see a mutter change have any effect for them I guess).

We already had a PPA [1] to try with something that fits the SRU policy [2] better but most likely won't help (yet would be great if it does).

Furthermore I now created a PPA with the bigger fix [3] backported to focal. That might be a harder ride through the SRU policy, but if that is the only thing fixing it we might need to consider it (we can then still break out the patches of 0.20 as needed).

I'd ask affected people to test both not just shortly but for quite a while as we all know these kind of issues are sometimes flaky and transient. Then please here give me feedback on how these PPAs would behave.

[1]: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4060
[2]: https://wiki.ubuntu.com/StableReleaseUpdates
[3]: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4076

P.S. also if you have multiple annoying issues after an upgrade that is sad to hear, but lets keep this bug about clipboard copy issues please and spawn other bugs for other - not necessarily related - problems.

Iain Lane (laney) on 2020-06-30

tags:

removed: champagne

Revision history for this message

Giacomo Tazzari (giact) wrote on 2020-08-10:

#38

@paelzer Hello Christian, since I am affected by this bug (Kubuntu 20.04) I wanted to try those PPAs mentioned in your last comment, but the links aren't working. Is there any update on all this?

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2020-08-10:

#39

Hi Gicaomo,
yeah every now and then I need to clean up most old builds to not get slapped by the admins :-)

I have refreshed them:
small fix: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4187/+packages
big fix (more likely to help, but not really SRUable to Fical): https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4188/+packages

It might take a bit until the are fully built.

Revision history for this message

Giacomo Tazzari (giact) wrote on 2020-08-11:

#40

Thank you, Christian!

I began testing the small fix first: I will use it for a couple weeks and see if the bug happens again.

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2020-08-12:

#41

Great - thank you for that Giacaomo

Note to myself, for the sake of finding things more easily next time:
https://code.launchpad.net/~paelzer/ubuntu/+source/spice-vdagent/+git/spice-vdagent/+ref/lp1872527-clipboard-handling-small
https://code.launchpad.net/~paelzer/ubuntu/+source/spice-vdagent/+git/spice-vdagent/+ref/lp1872527-clipboard-handling-big

Revision history for this message

Giacomo Tazzari (giact) wrote on 2020-08-19:

#42

Christian: the bug occurred again today while using the small fix version: so that one didn't solve it for me.

I will start using the big fix now and see how it goes through the next weeks.

Revision history for this message

Sebastian Haag (zoep) wrote on 2020-08-20:

#43

I came across the same issue with a guest distro.
I finally solved it by editing the XML File of the "Display Spice" section in the VM settings in virt-manager.

Open the details window of the affected VM in virt-manager.
Navigate to the section "Display Spice".
Click on the Tab "XML" (XML editing has to be enabled in the virt-manager settings).
Display Spice" section can be editted manually.
Add "<clipboard copypaste="no"/>" to the XML. It should look like this:
<graphics type="spice" autoport="yes">
<listen type="address"/>
<clipboard copypaste="no"/>
</graphics>

Source: https://unix.stackexchange.com/questions/341881/virt-manager-copy-and-paste-is-possible-to-disable-it

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2020-08-20:

#44

From
https://libvirt.org/formatdomain.html#graphical-framebuffers

"Copy & Paste functionality (via Spice agent) is set by the clipboard element. It is enabled by default, and can be disabled by setting the copypaste property to no. Since 0.9.3"

So yeah if disabling this turns out to be a reliable bug fix for those few that are affected that seems great. I'd not change the default though as for most setups/cases it seems to work.

@Sebastian - I assumed with that disabled guest/host clipboard copy is totally switched off, or is it working but without the issues described here?

Revision history for this message

Mirto Silvio Busico (m-busico) wrote on 2020-08-23:

#45

The problem is still here with Kubuntu 20.04 updated today for guest and host: clipboard works erratically and sometimes is bloked.
The proposed solution don't work fr me because I need to copy from host and paste in guest.

The only workaround I found is to use mate desktop in the guest.

Revision history for this message

Giacomo Tazzari (giact) wrote on 2020-09-01:

#46

@paelzer Christian: the bug still happens for me even when using the big fix solution.

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2020-09-01:

#47

Thanks Giacomo, then we are back to step I - not even knowing what to consider backporting :-/

Revision history for this message

Giacomo Tazzari (giact) wrote on 2020-09-01:

#48

Out of desperation, I now tried to enable "Ignore selection" (I don't really use that feature anyway) in my Clipboard settings on KDE on both Host and Guest, and see if that changes anything (while still using the big fix for the time being).

I am trying that because I noticed that often, when the bug occurs, the guest's clipboard contains sequence of bits of pasted text that get longer and longer, sometimes from the beginning of the text and sometimes from the end... and that seems to suggest that it's related to my target text being progressively selected over time.

I'll let you know if this changes anything.

Revision history for this message

Giacomo Tazzari (giact) wrote on 2020-09-12:

#49

@paelzer Christian: When checking my installed packages today I just realized that I didn't actually update spice-vdagent on my guest machine, I only updated it on the host (🤦‍♂️)... So, I am retesting again (starting from the big fix). I apologize for the mistake!

Revision history for this message

Giacomo Tazzari (giact) wrote on 2020-09-22:

#50

@paelzer I have an update.

After correctly applying the big fix on the guest too, the bug was still occurring but much more rarely.
But now, after I tried disabling Klipper (the KDE clipboard history manager) on both host and guest, the bug seems to have disappeared completely (and copy&paste still works fine, just without history).

I have yet to test what happens: if I keep Klipper disabled without any spice agent fix; and if I
keep Klipper disabled but with the small fix.

Revision history for this message

Jakub Klos (9v-ka2ub-3y) wrote on 2020-10-31:

#51

@paelzer Hello Christian, fix small fix did not help but bigger fix works for me fine on focal.

I did not have to update the spice-vdaagent on the host. All I did was update on the guest and things started working instantly (after reboot of course).

I can help in further testing if needed.

Now, the question is how do we go about this same problem on Windows guests? Do we need to apply the patch to the guest spice tools as well?

Thank you

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2020-11-02:

#52

Thanks Jakub for that confirmation!

But as discussed before that most likely means we can't fix it in Focal as the updates needed bring too much regression potential for a low prio issue that has alternative (to admit - non perfect) workarounds (e.g. the disabling of the clipboard - which avoids the issue but doesn't give you what you actually want).

It was very interesting to hear that a guest only update was enough for you to fix it. I wonder if even older guests - let us say Bionic - are affected as well or if now in between Bionic&Groovy being fixed Focal is the only bad one?
Do you happen to know about Bionic guests behavior?

Finally for Windows guests I have no idea what to do about, the spice guest bits there are not created from the same source/provider. But if indeed a guest update helped the Linux guest, then a guest update might help Windows as well. Did upgrading the host make any difference for this case when you used a Windows guest?

Revision history for this message

Jakub Klos (9v-ka2ub-3y) wrote on 2020-11-02:

#53

@paelzer
Thank you, Christian.
Yes, I am aware of the workaround as I am using it on Windows (stopping the VDAgent is sufficient on the guest). The only way to use the guest reasonably (you would never tell how copy/paste is used frequently during coding)

Currently, I am happy with the patch on focal. It would be nice if the fix gets in the future updates as well. I am willing to test a few distros if you need.

I did not test Bionic but I tried both Windows10 yesterday and found out the issue is the same indeed on both Win7 and Win10.

I tried updating the host with the patched vdagent and it did not help neither in Windows nor Focal.

Please, let me know what you want me to test and I will do my best

Revision history for this message

Jakub Klos (9v-ka2ub-3y) wrote on 2020-11-09:

#54

Actually, the issue for both Linux and Windows guests is resolved by this fix
https://gitlab.freedesktop.org/spice/spice-gtk/-/issues/82

You do not need to do anything else just install the latest 0.38 spice-client libs on the host (on Ubuntu 20.04):

libspice-client-glib-2.0-8_0.38-2ubuntu1_amd64.deb
libspice-client-gtk-3.0-5_0.38-2ubuntu1_amd64.deb
spice-client-glib-usb-acl-helper_0.38-2ubuntu1_amd64.deb

Then it works properly on all guests
I think this ticket can be closed...

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2020-11-10:

#55

But being a protocol change [1] I'm unsure we can SRU this to Focal easily.
I wonder that you say only the host needs to change as the discussion on [2] says you'll need the new protocol on the guest as well.

I'm glad we have it fixed going forward, but as I said I'm rather unsure about SRUing this change without a much deeper evaluation.

[1]: https://gitlab.freedesktop.org/spice/spice-gtk/-/merge_requests/25/commits
[2]: https://gitlab.freedesktop.org/spice/spice-gtk/-/issues/82

Changed in spice-vdagent (Ubuntu Focal):
status:	Incomplete → Invalid
Changed in spice-protocol (Ubuntu Focal):
status:	Incomplete → Triaged
importance:	Undecided → Wishlist
Changed in spice-gtk (Ubuntu Focal):
status:	New → Triaged
importance:	Undecided → Wishlist
Changed in spice-gtk (Ubuntu):
status:	New → Fix Released

Revision history for this message

launcher of pad's (321launch) wrote on 2020-12-16:

#56

issue still present after installing
libspice-client-glib-2.0-8_0.38-2ubuntu1_amd64.deb
libspice-client-gtk-3.0-5_0.38-2ubuntu1_amd64.deb
spice-client-glib-usb-acl-helper_0.38-2ubuntu1_amd64.deb
and rebooting

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2021-04-14:

#57

Recent Bug 1922942 made me aware that this is again showing up in recent versions.
Kubuntu 21.04 shows very similar symptoms, but non-KDE systems seem not affected at all.
I was able to use it without any trouble on gnome based Ubuntus (Host and Guest).

Does any of the involved/subscribed people have a good idea why this might be different for KDE guests?

@All - have you recently tried mixed combinations yet of either Host or Guest being non-KDE - What was the result of that?

Revision history for this message

Jeff Francus (jeff-fra) wrote on 2021-04-15:

#58

I noticed this issue with Kubuntu (Plasma) host and Ubuntu (GNOME) guest.

I thought I was the only one affected since this makes almost impossible to use VMs with GUI (desktop). Not that you wouldn't be able to run them but that you realize that you use Ctrl+c/Ctrl+v so often that when it doesn't work 100% it sooo bad experience that you rather not to use VMs at all. And VirtualBox is not an answer ;-).

Btw. Windows 10 guest is all right.

Thank you Christian for asking and investigating.

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2021-10-13:

#59

As outlined in #55 unless we identify a smaller set of fixes I'm unsure what we could do for Focal.

I'm out of ideas, the only one good thing is that it seems better in later versions and got more rare. But I hate when I do not understand all of a problem, here I might need help from Desktop-oriented thinking - hence I'll subscribe the desktop team if they might know better.

Changed in spice-protocol (Ubuntu Focal):
status:	Triaged → Won't Fix
Changed in spice-gtk (Ubuntu Focal):
status:	Triaged → Won't Fix

Ubuntu
virt-manager package

Clipboard doesn't work 100% of the time in Ubuntu 20.04 (in KVM guests)

Bug Description

Duplicates of this bug

Other bug subscribers

Bug attachments

Remote bug watches

	Status	Importance	Assigned to
qemu (Ubuntu)	Invalid	Undecided	Unassigned
spice (Fedora)	Unknown	Unknown	redhat-bugs #1600798
spice (Ubuntu)	Invalid	Undecided	Unassigned
spice-gtk (Ubuntu)	Fix Released	Undecided	Unassigned
Focal	Won't Fix	Wishlist	Unassigned
spice-protocol (Ubuntu)	Fix Released	Undecided	Unassigned
Focal	Won't Fix	Wishlist	Unassigned
spice-vdagent (Debian)	Fix Released	Unknown	debbugs #854936
spice-vdagent (Ubuntu)	Fix Released	Undecided	Unassigned
Focal	Invalid	Undecided	Unassigned
virt-manager (Ubuntu)	Invalid	Undecided	Unassigned

Ubuntuvirt-manager package

Clipboard doesn't work 100% of the time in Ubuntu 20.04 (in KVM guests)

Bug Description

Duplicates of this bug

Other bug subscribers

Bug attachments

Remote bug watches

Ubuntu
virt-manager package