Happened again:
May 11 17:05:50 saegusa gnome-shell[3619]: WL: compositor bug: The compositor tried to use an object from one client in a ’wl_pointer.enter’ for a different client.
May 11 17:05:50 saegusa gnome-shell[3619]: WL: error in client communication (pid 5170)
May 11 17:05:50 saegusa gnome-terminal-[5170]: Error reading events from display: Katkennut putki
May 11 17:05:50 saegusa systemd[3544]: gnome-terminal-server.service: Main process exited, code=exited, status=1/FAILURE
May 11 17:05:50 saegusa systemd[3544]: gnome-terminal-server.service: Failed with result ’exit-code’.
May 11 17:05:50 saegusa systemd[3544]: vte-spawn-b269c64d-5376-49ec-83fc-9f4806ac4b30.scope: Succeeded.
May 11 17:05:50 saegusa systemd[3544]: vte-spawn-3294a176-7b32-4995-a11b-fe0fea8b07bc.scope: Succeeded.
May 11 17:05:50 saegusa systemd[3544]: vte-spawn-0b59afd0-1aed-4081-a7d1-801e7c405399.scope: Succeeded.
May 11 17:05:51 saegusa systemd[3544]: Started Application launched by gnome-shell.
But there’s still nothing in /var/crash, nor on the Error Tracker (aside from the aforementioned, unrelated crash from last week).
Turns out the online service was just a little slow to update, and there are in fact reports sent. But the only one post-20.04-upgrade is [1] from last week, which is a gnome-shell crash and IIRC, unrelated to the terminal issue here. It seemed to be triggered by something related to media files and Nautilus, and the logs from the time are different; I’m attaching them here. (I had separated gnome-shell logs out from the main syslog, but I’ve since reverted back to having everything in syslog.)
* [1] https://errors.ubuntu.com/oops/26828e26-8fc9-11ea-acd0-fa163e983629
Thanks for the instructions, Daniel! I found no crash files either locally or online, so I’ve implemented the workaround now, and will try to trigger the crash again.
Since upgrading to 20.04 and switching to Wayland, Gnome terminal occasionally crashes. I interpret the corresponding logs to mean that it’s actually Wayland that fails to do something in the background, which then takes down Gnome terminal:
touko 08 11:35:16 saegusa gnome-shell[4227]: WL: compositor bug: The compositor tried to use an object from one client in a 'wl_pointer.enter' for a different client.
touko 08 11:35:16 saegusa gnome-shell[4227]: WL: error in client communication (pid 11639)
touko 08 11:35:16 saegusa gnome-terminal-[11639]: Error reading events from display: Katkennut putki
touko 08 11:35:16 saegusa systemd[4153]: vte-spawn-bbca1723-5987-4ccf-98cb-3389ad05641e.scope: Succeeded.
touko 08 11:35:16 saegusa systemd[4153]: vte-spawn-fbe02208-95df-4cf4-bfbe-fffc71d6bc7e.scope: Succeeded.
touko 08 11:35:16 saegusa systemd[4153]: gnome-terminal-server.service: Main process exited, code=exited, status=1/FAILURE
touko 08 11:35:16 saegusa systemd[4153]: gnome-terminal-server.service: Failed with result 'exit-code'.
I have yet to nail down the precise circumstances, as this has (so far) been somewhat rare, having occurred perhaps once or twice a week.
Since the log mentions pointer, I should perhaps mention that I’ve set `org.gnome.desktop.wm.preferences` > `focus-mode` to `mouse`. Gnome terminal also exhibits other misbehaviour wrt. to this, occasionally refusing to get focus, or alternatively losing the focus, despite mouse cursor being over the terminal window.
Boinc-client logs ”No protocol specified” incessantly, twice every second on my setup.
-- Logs begin at Wed 2020-03-25 14:45:19 EET, end at Fri 2020-05-01 17:14:34 EEST. --
touko 01 00:00:00 saegusa boinc[2083]: No protocol specified
touko 01 00:00:00 saegusa boinc[2083]: No protocol specified
touko 01 00:00:01 saegusa boinc[2083]: No protocol specified
touko 01 00:00:01 saegusa boinc[2083]: No protocol specified
touko 01 00:00:02 saegusa boinc[2083]: No protocol specified
touko 01 00:00:02 saegusa boinc[2083]: No protocol specified
touko 01 00:00:03 saegusa boinc[2083]: No protocol specified
touko 01 00:00:03 saegusa boinc[2083]: No protocol specified
touko 01 00:00:04 saegusa boinc[2083]: No protocol specified
touko 01 00:00:04 saegusa boinc[2083]: No protocol specified
touko 01 00:00:05 saegusa boinc[2083]: No protocol specified
touko 01 00:00:05 saegusa boinc[2083]: No protocol specified
touko 01 00:00:06 saegusa boinc[2083]: No protocol specified
…and on and on…
touko 01 17:14:54 saegusa boinc[2083]: No protocol specified
touko 01 17:14:55 saegusa boinc[2083]: No protocol specified
touko 01 17:14:55 saegusa boinc[2083]: No protocol specified
touko 01 17:14:56 saegusa boinc[2083]: No protocol specified
touko 01 17:14:56 saegusa boinc[2083]: No protocol specified
touko 01 17:14:57 saegusa boinc[2083]: No protocol specified
touko 01 17:14:57 saegusa boinc[2083]: No protocol specified
touko 01 17:14:58 saegusa boinc[2083]: No protocol specified
touko 01 17:14:58 saegusa boinc[2083]: No protocol specified
touko 01 17:14:59 saegusa boinc[2083]: No protocol specified
touko 01 17:14:59 saegusa boinc[2083]: No protocol specified
touko 01 17:15:00 saegusa boinc[2083]: No protocol specified
touko 01 17:15:00 saegusa boinc[2083]: No protocol specified
touko 01 17:15:01 saegusa boinc[2083]: No protocol specified
touko 01 17:15:01 saegusa boinc[2083]: No protocol specified
touko 01 17:15:02 saegusa boinc[2083]: No protocol specified
touko 01 17:15:02 saegusa boinc[2083]: No protocol specified
With `media.autoplay.enabled.user-gestures-needed` set to false and `media.autoplay.default` set to 1 (block audio), which is the default (and other autoplay-related settings in their defaults as well), a Twitch video can only be either paused or playing muted; unmuting the video pauses it and vice versa.
== Steps to reproduce ==
1. Open about:config
2. Search for autoplay in the settings
3. Set media.autoplay.enabled.user-gestures-needed to false
4. Set media.autoplay.default to 1
5. Open a Twitch VOD, for instance https://www.twitch.tv/videos/280106033
6. Try to unmute the video
== What happens ==
The video is unmuted, but also paused
== What I expect to happen ==
For the video to continue playing, unmuted
When trying without root:
$ dd if=/dev/zero bs=16M count=1 of=test.img
1+0 records in
1+0 records out
16777216 bytes (17 MB, 16 MiB) copied, 0.0326881 s, 513 MB/s
$ echo foo | cryptsetup luksFormat test.img –
Not compatible PBKDF options.
Whereas for root it still works:
# dd if=/dev/zero bs=16M count=1 of=test.img
Please touch the device.
1+0 records in
1+0 records out
16777216 bytes (17 MB, 16 MiB) copied, 0.0183403 s, 915 MB/s
# echo foo | sudo cryptsetup luksFormat test.img –
#
For a workaround (from upstream report) with non-root, specify –type luks1:
$ dd if=/dev/zero bs=16M count=1 of=test.img
1+0 records in
1+0 records out
16777216 bytes (17 MB, 16 MiB) copied, 0.0138972 s, 1.2 GB/s
$ echo foo | cryptsetup luksFormat –type luks1 test.img –
$
Oh and I’m using Wayland, in case it matters here. Haven’t yet tried whether Xorg is similarly affected.
Still present in 20.04 (Focal) with vlc 3.0.9.2-1, though here at least it seems to only affect some URLs, not all. When I view a stream from my local webcam, vlc -vvv in the terminal shows
main playlist debug: incoming request – stopping current input
as the final message, and does not exit (after closing the window; Ctrl-Q still works). But when streaming from Wowza’s RTSP test stream [1], vlc exits just fine after closing the window.
Debian bug 916595 [2] and related VLC ticket [3] mention disabling hardware acceleration as a workaround, but even so I was unable to make it work (i.e. exit properly).
Possibly related: Ubuntu bug #1847162. There’s also been discussion about the issue over on Manjaro forums [4].
* [1] rtsp://wowzaec2demo.streamlock.net/vod/mp4:BigBuckBunny_115k.mov
* [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916595
* [3] https://trac.videolan.org/vlc/ticket/20627
* [4] https://forum.manjaro.org/t/vlc-not-closing/69965/2