Bug 1882718
| Summary: | Server crashes after one connection attempt, all subsequent attempts will fail | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Alessio <alciregi> |
| Component: | libvncserver | Assignee: | Rex Dieter <rdieter> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 33 | CC: | awilliam, gmarr, jadahl, kparal, lruzicka, mclasen, negativo17, rdieter, robatino |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | AcceptedBlocker | ||
| Fixed In Version: | libvncserver-0.9.13-9.fc33 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-10-14 00:42:12 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1766777 | ||
The subsequent connection crash is already reported upstream: https://gitlab.gnome.org/GNOME/gnome-remote-desktop/-/issues/45 Proposed as a Blocker for 33-final by Fedora user alciregi using the blocker tracking app because: All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use. Enabling desktop sharing is a quite common task. Discussed during the 2020-09-28 blocker review meeting: [0] The decision to delay the classification of this as a blocker bug was made as we want confirmation that this bug only occurs with VNC sessions and that VNC is intended to be covered in the "default panel must function correctly" criterion. [0] https://meetbot.fedoraproject.org/fedora-blocker-review/2020-09-28/f33-blocker-review.2020-09-28-16.01.txt The crash in rfbSendRectEncodingZlib() is a bug in libvncserver fixed by https://github.com/LibVNC/libvncserver/pull/444. As for closing the connection when locking the screen, this is by design: https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1210 (In reply to Jonas Ă…dahl from comment #4) > > As for closing the connection when locking the screen, this is by design: > https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1210 So this is a different behaviour from the past, as far as I can remember, is it? Yes, kind of. In the past screen casting via org.gnome.Shell.Screencast behaved this way, now we expanded to the ones via PipeWire too. Screen sharing the lock screen etc will need careful considerations IMHO.
> As for closing the connection when locking the screen, this is by design:
> https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1210
I often use screen sharing to work on my laptop from my PC. I do not think that this should be a required behaviour, that when the laptop locks the screen, I will be disconnected from it.
I am using a dedicated VNC server running on my laptop so I did not experience this kind of behaviour, but I think another use case is gone for users that do not want to fiddle with VNC settings too much. Can't you reconsider?
(In reply to Lukas Ruzicka from comment #7) > > As for closing the connection when locking the screen, this is by design: > > https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1210 > > I often use screen sharing to work on my laptop from my PC. I do not think > that this should be a required behaviour, that when the laptop locks the > screen, I will be disconnected from it. > I am using a dedicated VNC server running on my laptop so I did not > experience this kind of behaviour, but I think another use case is gone for > users that do not want to fiddle with VNC settings too much. Can't you > reconsider? Can you open a bug upstream to keep track? The problem here is that, if you have a locked session, say at work, and you connect to it and unlock from home, you'd effectively unlock and turn on the monitor at work for anyone to see, which is a pretty scary default. In the mean time, you can avoid this by running this in looking glass: global.backend.get_remote_access_controller().inhibit_remote_access = () => {} global.backend.get_remote_access_controller().uninhibit_remote_access = () => {} With that, it should behave exactly as it did before. I can confirm the crash in comment 0. Only the first connection goes through, no second connection is possible. Even if the first connection is not fully established (e.g. you reject it, or it ends with "no matching security types" which happens with vncclient), you can't connect again. Maybe I'm stating the obvious, I just wanted to clarify the crash behavior and its effects. I'm adjusting this bug to be about the crash, as the "can't login when locked" thing is more properly addressed upstream in the ticket lruzicka filed. Discussed during the 2020-10-05 blocker review meeting: [0] The decision to classify this bug as an "AcceptedBlocker (Final)" was made as it violates the following criterion: "All applications that can be launched...after a default installation of Fedora Workstation...must start successfully and withstand a basic functionality test", counting screen sharing as part of Settings, as the crash means only one screen sharing session can be attempted, after which the server crashes and all subsequent attempts will fail. [0] https://meetbot.fedoraproject.org/fedora-blocker-review/2020-10-05/f33-blocker-review.2020-10-05-16.00.txt I think this should be moved to libvncserver to apply the existing upstream crash fix. FEDORA-2020-c66310a3b6 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-c66310a3b6 Someone called for a provenpackager? :) jadahl, I did some rebasing to get all the patches to apply. I *think* 0003-libvncserver-auth-don-t-keep-security-handlers-from-.patch should still work on top of 0002-libvncserver-Add-channel-security-handlers.patch , but if you could confirm that shouldn't cause any problems it'd be great. FEDORA-2020-c66310a3b6 has been pushed to the Fedora 33 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-c66310a3b6` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-c66310a3b6 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. So now I actually look at the backtraces, I don't think this and https://gitlab.gnome.org/GNOME/gnome-remote-desktop/-/issues/45 are actually the same at all. The backtraces posted there don't run through rfbSendRectEncodingZlib at all. I'm curious to know if, with the update I sent, folks now actually do run into the backtrace from upstream #45... With libvncserver-0.9.13-8.fc33 I get a gnome-remote-desktop crash on every second connection attempt. I get an approval notification, but when I confirm it, the server crashes:
Oct 12 15:32:23 f33 pipewire[2500]: [E][000000274.688343][module-access.c:101 check_flatpak()] failed to open "/proc/1591/root": Permission denied
Oct 12 15:32:23 f33 pipewire[2500]: [W][000000274.689351][module-access.c:194 context_check_access()] access 0x5654a747cd30: client 0x5654a74d6b70 sandbox check failed: Permission denied
Oct 12 15:32:23 f33 gnome-shell[1591]: g_udev_client_query_by_device_file: assertion 'device_file != NULL' failed
Oct 12 15:32:23 f33 gnome-remote-desktop-daemon[2815]: [W][000000274.747494][remote-node.c:650 client_node_port_use_buffers()] Failed to mlock memory 0x7f03a90dd000 589888: This is not a problem but for best performance, consider increasing RLIMIT_MEMLOCK
Oct 12 15:32:23 f33 gnome-remote-desktop-daemon[2815]: [W][000000274.747521][remote-node.c:650 client_node_port_use_buffers()] Failed to mlock memory 0x7f03a904c040 589888: This is not a problem but for best performance, consider increasing RLIMIT_MEMLOCK
Oct 12 15:32:23 f33 gnome-remote-desktop-daemon[2815]: [W][000000274.747527][remote-node.c:650 client_node_port_use_buffers()] Failed to mlock memory 0x7f03a8fbb080 589888: This is not a problem but for best performance, consider increasing RLIMIT_MEMLOCK
Oct 12 15:32:23 f33 gnome-remote-desktop-daemon[2815]: [W][000000274.747532][remote-node.c:650 client_node_port_use_buffers()] Failed to mlock memory 0x7f03a8f2a0c0 589888: This is not a problem but for best performance, consider increasing RLIMIT_MEMLOCK
Oct 12 15:32:23 f33 gnome-remote-desktop-daemon[2815]: [W][000000274.747537][remote-node.c:650 client_node_port_use_buffers()] Failed to mlock memory 0x7f03a8e99100 589888: This is not a problem but for best performance, consider increasing RLIMIT_MEMLOCK
Oct 12 15:32:23 f33 gnome-remote-desktop-daemon[2815]: [W][000000274.747541][remote-node.c:650 client_node_port_use_buffers()] Failed to mlock memory 0x7f03a8e08140 589888: This is not a problem but for best performance, consider increasing RLIMIT_MEMLOCK
Oct 12 15:32:23 f33 gnome-remote-desktop-daemon[2815]: [W][000000274.747546][remote-node.c:650 client_node_port_use_buffers()] Failed to mlock memory 0x7f03a8d77180 589888: This is not a problem but for best performance, consider increasing RLIMIT_MEMLOCK
Oct 12 15:32:23 f33 gnome-remote-desktop-daemon[2815]: [W][000000274.747551][remote-node.c:650 client_node_port_use_buffers()] Failed to mlock memory 0x7f03a8ce61c0 589888: This is not a problem but for best performance, consider increasing RLIMIT_MEMLOCK
Oct 12 15:32:33 f33 gnome-shell[1591]: libinput error: event5 - spice vdagent tablet: client bug: event processing lagging behind by 13ms, your system is too slow
Oct 12 15:32:34 f33 pipewire[2500]: [E][000000285.402250][module-access.c:101 check_flatpak()] failed to open "/proc/1591/root": Permission denied
Oct 12 15:32:34 f33 pipewire[2500]: [W][000000285.402277][module-access.c:194 context_check_access()] access 0x5654a747cd30: client 0x5654a761b8f0 sandbox check failed: Permission denied
Oct 12 15:32:34 f33 gnome-shell[1591]: g_udev_client_query_by_device_file: assertion 'device_file != NULL' failed
Oct 12 15:32:34 f33 gnome-remote-desktop-daemon[2815]: [W][000000285.424125][remote-node.c:650 client_node_port_use_buffers()] Failed to mlock memory 0x7f03a9c33000 589888: This is not a problem but for best performance, consider increasing RLIMIT_MEMLOCK
Oct 12 15:32:34 f33 gnome-remote-desktop-daemon[2815]: [W][000000285.424724][remote-node.c:650 client_node_port_use_buffers()] Failed to mlock memory 0x7f03a9230040 589888: This is not a problem but for best performance, consider increasing RLIMIT_MEMLOCK
Oct 12 15:32:34 f33 gnome-remote-desktop-daemon[2815]: [W][000000285.424894][remote-node.c:650 client_node_port_use_buffers()] Failed to mlock memory 0x7f03a919f080 589888: This is not a problem but for best performance, consider increasing RLIMIT_MEMLOCK
Oct 12 15:32:34 f33 gnome-remote-desktop-daemon[2815]: [W][000000285.424992][remote-node.c:650 client_node_port_use_buffers()] Failed to mlock memory 0x7f03a910e0c0 589888: This is not a problem but for best performance, consider increasing RLIMIT_MEMLOCK
Oct 12 15:32:34 f33 gnome-remote-desktop-daemon[2815]: [W][000000285.425074][remote-node.c:650 client_node_port_use_buffers()] Failed to mlock memory 0x7f03a907d100 589888: This is not a problem but for best performance, consider increasing RLIMIT_MEMLOCK
Oct 12 15:32:34 f33 gnome-remote-desktop-daemon[2815]: [W][000000285.425156][remote-node.c:650 client_node_port_use_buffers()] Failed to mlock memory 0x7f03a8fec140 589888: This is not a problem but for best performance, consider increasing RLIMIT_MEMLOCK
Oct 12 15:32:34 f33 gnome-remote-desktop-daemon[2815]: [W][000000285.425300][remote-node.c:650 client_node_port_use_buffers()] Failed to mlock memory 0x7f03a8f5b180 589888: This is not a problem but for best performance, consider increasing RLIMIT_MEMLOCK
Oct 12 15:32:34 f33 gnome-remote-desktop-daemon[2815]: [W][000000285.425405][remote-node.c:650 client_node_port_use_buffers()] Failed to mlock memory 0x7f03a8eca1c0 589888: This is not a problem but for best performance, consider increasing RLIMIT_MEMLOCK
Oct 12 15:32:34 f33 gnome-remote-desktop-daemon[2815]: double free or corruption (!prev)
Oct 12 15:32:34 f33 audit[2815]: ANOM_ABEND auid=1000 uid=1000 gid=1000 ses=3 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=2815 comm="gnome-remote-de" exe="/usr/libexec/gnome-remote-desktop-daemon" sig=6 res=1
Oct 12 15:32:34 f33 audit: BPF prog-id=65 op=LOAD
Oct 12 15:32:34 f33 audit: BPF prog-id=66 op=LOAD
Oct 12 15:32:34 f33 audit: BPF prog-id=67 op=LOAD
Oct 12 15:32:34 f33 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-coredump@3-2830-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Oct 12 15:32:34 f33 systemd[1]: Started Process Core Dump (PID 2830/UID 0).
Oct 12 15:32:34 f33 systemd[1459]: gnome-remote-desktop.service: Main process exited, code=dumped, status=6/ABRT
Oct 12 15:32:34 f33 systemd[1459]: gnome-remote-desktop.service: Failed with result 'core-dump'.
Oct 12 15:32:34 f33 systemd[1459]: gnome-remote-desktop.service: Consumed 1.122s CPU time.
Oct 12 15:32:34 f33 gnome-shell[1591]: D-Bus client with active sessions vanished
Oct 12 15:32:34 f33 systemd-coredump[2831]: [🡕] Process 2815 (gnome-remote-de) of user 1000 dumped core.
Stack trace of thread 2815:
#0 0x00007f03afb05bc5 raise (libc.so.6 + 0x3dbc5)
#1 0x00007f03afaee8a4 abort (libc.so.6 + 0x268a4)
#2 0x00007f03afb48127 __libc_message (libc.so.6 + 0x80127)
#3 0x00007f03afb4fe1c malloc_printerr (libc.so.6 + 0x87e1c)
#4 0x00007f03afb516ac _int_free (libc.so.6 + 0x896ac)
#5 0x0000557da2909108 do_render (gnome-remote-desktop-daemon + 0x19108)
#6 0x00007f03a9c0d408 flush_items (libspa-support.so + 0x6408)
#7 0x00007f03a9c0c62e source_event_func (libspa-support.so + 0x562e)
#8 0x00007f03a9c0e5db loop_iterate (libspa-support.so + 0x75db)
#9 0x0000557da2908e76 pipewire_loop_source_dispatch (gnome-remote-desktop-daemon + 0x18e76)
#10 0x00007f03b0345ff7 g_main_context_dispatch (libglib-2.0.so.0 + 0x51ff7)
#11 0x00007f03b0396bb8 g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0xa2bb8)
#12 0x00007f03b034341f g_main_context_iteration (libglib-2.0.so.0 + 0x4f41f)
#13 0x00007f03b02043e5 g_application_run (libgio-2.0.so.0 + 0xd53e5)
#14 0x0000557da28f86e6 main (gnome-remote-desktop-daemon + 0x86e6)
#15 0x00007f03afaf01a2 __libc_start_main (libc.so.6 + 0x281a2)
#16 0x0000557da28f87ee _start (gnome-remote-desktop-daemon + 0x87ee)
Stack trace of thread 2820:
#0 0x00007f03afbbea0f __poll (libc.so.6 + 0xf6a0f)
#1 0x00007f03b0396b4e g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0xa2b4e)
#2 0x00007f03b03456cb g_main_loop_run (libglib-2.0.so.0 + 0x516cb)
#3 0x00007f03b02376b6 gdbus_shared_thread_func.lto_priv.0 (libgio-2.0.so.0 + 0x1086b6)
#4 0x00007f03b0372f2e g_thread_proxy (libglib-2.0.so.0 + 0x7ef2e)
#5 0x00007f03af5aa3f9 start_thread (libpthread.so.0 + 0x93f9)
#6 0x00007f03afbc9b03 __clone (libc.so.6 + 0x101b03)
Stack trace of thread 2819:
#0 0x00007f03afbbea0f __poll (libc.so.6 + 0xf6a0f)
#1 0x00007f03b0396b4e g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0xa2b4e)
#2 0x00007f03b034341f g_main_context_iteration (libglib-2.0.so.0 + 0x4f41f)
#3 0x00007f03ac5fe64d dconf_gdbus_worker_thread (libdconfsettings.so + 0x664d)
#4 0x00007f03b0372f2e g_thread_proxy (libglib-2.0.so.0 + 0x7ef2e)
#5 0x00007f03af5aa3f9 start_thread (libpthread.so.0 + 0x93f9)
#6 0x00007f03afbc9b03 __clone (libc.so.6 + 0x101b03)
Stack trace of thread 2818:
#0 0x00007f03afbbea0f __poll (libc.so.6 + 0xf6a0f)
#1 0x00007f03b0396b4e g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0xa2b4e)
#2 0x00007f03b034341f g_main_context_iteration (libglib-2.0.so.0 + 0x4f41f)
#3 0x00007f03b0345051 glib_worker_main (libglib-2.0.so.0 + 0x51051)
#4 0x00007f03b0372f2e g_thread_proxy (libglib-2.0.so.0 + 0x7ef2e)
#5 0x00007f03af5aa3f9 start_thread (libpthread.so.0 + 0x93f9)
#6 0x00007f03afbc9b03 __clone (libc.so.6 + 0x101b03)
Stack trace of thread 2829:
#0 0x00007f03afbc9e4e epoll_wait (libc.so.6 + 0x101e4e)
#1 0x00007f03a9c171b4 impl_pollfd_wait (libspa-support.so + 0x101b4)
#2 0x00007f03a9c0e544 loop_iterate (libspa-support.so + 0x7544)
#3 0x00007f03b005cd67 do_loop (libpipewire-0.3.so.0 + 0x26d67)
#4 0x00007f03af5aa3f9 start_thread (libpthread.so.0 + 0x93f9)
#5 0x00007f03afbc9b03 __clone (libc.so.6 + 0x101b03)
Oct 12 15:32:34 f33 systemd[1]: systemd-coredump: Succeeded.
Oct 12 15:32:34 f33 audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-coredump@3-2830-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Oct 12 15:32:34 f33 systemd[1459]: gnome-remote-desktop.service: Scheduled restart job, restart counter is at 4.
Oct 12 15:32:34 f33 systemd[1459]: Stopped GNOME Remote Desktop.
Oct 12 15:32:34 f33 systemd[1459]: gnome-remote-desktop.service: Consumed 1.122s CPU time.
Oct 12 15:32:34 f33 systemd[1459]: Starting GNOME Remote Desktop...
Oct 12 15:32:34 f33 audit: BPF prog-id=67 op=UNLOAD
Oct 12 15:32:34 f33 audit: BPF prog-id=66 op=UNLOAD
Oct 12 15:32:34 f33 audit: BPF prog-id=65 op=UNLOAD
Oct 12 15:32:34 f33 systemd[1459]: Started GNOME Remote Desktop.
Oct 12 15:32:34 f33 gnome-remote-de[2837]: Failed to initialize RDP server: Couldn't find the server certificate or private keyfile
Unfortunately ABRT doesn't pick up the crash for some reason. I can run it through gdb manually if necessary. This line:
Oct 12 15:32:34 f33 systemd[1459]: gnome-remote-desktop.service: Scheduled restart job, restart counter is at 4.
sounds like I won't be able to reconnect the second time forever.
The root cause probably is this?
Oct 12 15:32:34 f33 gnome-remote-desktop-daemon[2815]: double free or corruption (!prev)
> Unfortunately ABRT doesn't pick up the crash for some reason. I can run it through gdb manually if necessary. This line:
Can you, with "bt full"?
kparal: I'll note that's clearly not the *same* crash. And if it only happens every second attempt, whereas this crash was said to happen on every attempt after the first, that seems like evidence that the update *does* fix *this* crash. The traceback here does actually look *more* like the one in https://gitlab.gnome.org/GNOME/gnome-remote-desktop/-/issues/45 . They at least share this much in common: #5 0x0000557da2909108 do_render (gnome-remote-desktop-daemon + 0x19108) #6 0x00007f03a9c0d408 flush_items (libspa-support.so + 0x6408) #7 0x00007f03a9c0c62e source_event_func (libspa-support.so + 0x562e) #8 0x00007f03a9c0e5db loop_iterate (libspa-support.so + 0x75db) #9 0x0000557da2908e76 pipewire_loop_source_dispatch (gnome-remote-desktop-daemon + 0x18e76) #10 0x00007f03b0345ff7 g_main_context_dispatch (libglib-2.0.so.0 + 0x51ff7) #11 0x00007f03b0396bb8 g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0xa2bb8) #12 0x00007f03b034341f g_main_context_iteration (libglib-2.0.so.0 + 0x4f41f) #13 0x00007f03b02043e5 g_application_run (libgio-2.0.so.0 + 0xd53e5) #14 0x0000557da28f86e6 main (gnome-remote-desktop-daemon + 0x86e6) and in fact Greyson Christoforo's traceback from upstream comments looks even more similar to this one... Created https://koji.fedoraproject.org/koji/taskinfo?taskID=53298735 with https://gitlab.gnome.org/GNOME/gnome-remote-desktop/-/merge_requests/21 ported over to F33. I can still see a crash in libvncserver sometimes after reconnecting though. Debugged the "rich cursor" crash, tracked it down to libvncserver, fixed it, then discovered it had been fixed upstream recently: https://github.com/LibVNC/libvncserver/commit/d138cf90130b0e8d5062f136ecdbcaa85e734d5d FEDORA-2020-c66310a3b6 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-c66310a3b6 OK, I updated the update with jadahl's new gnome-remote-desktop build, and the fix for the cursor crash added to libvncserver. Can folks try now and see how it goes? FEDORA-2020-c66310a3b6 has been pushed to the Fedora 33 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-c66310a3b6` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-c66310a3b6 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. (In reply to Fedora Update System from comment #24) > FEDORA-2020-c66310a3b6 has been submitted as an update to Fedora 33. > https://bodhi.fedoraproject.org/updates/FEDORA-2020-c66310a3b6 Works perfectly :-) FEDORA-2020-c66310a3b6 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report. |
Description of problem: Enable Screen Sharing in GNOME settings -> Sharing. Set a password. From a remote machine connect via VNC. Ok, it works. Wait for the screen lock, or press Super+L The VNC client session will be closed. Trying to reconnect, the client ask for the password, but it can't login. This while the screen is still locked. Then unlock the screen, enter the user password. From the client, now it seems to connect, but the client window closes. On the machine sharing the screen (journalctl) gnome-remote-desktop produces a core-dump. Sep 25 14:27:49 localhost.localdomain gnome-remote-de[4392]: Failed to initialize RDP server: Couldn't find the server certificate or private keyfile Sep 25 14:27:49 localhost.localdomain systemd-coredump[4391]: [🡕] Process 4053 (gnome-remote-de) of user 1000 dumped core. Stack trace of thread 4053: #0 0x00007fb9baca0175 realloc (libc.so.6 + 0x8d175) #1 0x00007fb9bb14d90b rfbSendRectEncodingZlib (libvncserver.so.1 + 0x3390b) ... Trying again to connect with a VNC client, now it works. But again, if you lock the screen, the problem comes back.