Bug 1882718 - Server crashes after one connection attempt, all subsequent attempts will fail
Summary: Server crashes after one connection attempt, all subsequent attempts will fail
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: libvncserver
Version: 33
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Rex Dieter
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker
Depends On:
Blocks: F33FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2020-09-25 12:35 UTC by Alessio
Modified: 2020-10-14 00:42 UTC (History)
9 users (show)

Fixed In Version: libvncserver-0.9.13-9.fc33
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-10-14 00:42:12 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Alessio 2020-09-25 12:35:24 UTC
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.

Comment 1 Alessio 2020-09-25 13:16:55 UTC
The subsequent connection crash is already reported upstream:
https://gitlab.gnome.org/GNOME/gnome-remote-desktop/-/issues/45

Comment 2 Fedora Blocker Bugs Application 2020-09-27 16:43:45 UTC
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.

Comment 3 Geoffrey Marr 2020-09-28 17:00:06 UTC
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

Comment 4 Jonas Ådahl 2020-09-28 17:05:24 UTC
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

Comment 5 Alessio 2020-09-28 17:34:15 UTC
(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?

Comment 6 Jonas Ådahl 2020-09-28 17:56:30 UTC
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.

Comment 7 Lukas Ruzicka 2020-09-29 11:13:56 UTC
> 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?

Comment 8 Jonas Ådahl 2020-09-29 12:11:25 UTC
(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.

Comment 9 Lukas Ruzicka 2020-10-02 13:11:01 UTC
Sure, https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3212

Comment 10 Kamil Páral 2020-10-05 12:40:47 UTC
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.

Comment 11 Adam Williamson 2020-10-05 16:59:52 UTC
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.

Comment 12 Geoffrey Marr 2020-10-05 19:56:19 UTC
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

Comment 13 Matthias Clasen 2020-10-09 15:02:50 UTC
I think this should be moved to libvncserver to apply the existing upstream crash fix.

Comment 14 Fedora Update System 2020-10-09 23:45:27 UTC
FEDORA-2020-c66310a3b6 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-c66310a3b6

Comment 15 Adam Williamson 2020-10-09 23:46:32 UTC
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.

Comment 16 Fedora Update System 2020-10-10 17:46:36 UTC
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.

Comment 17 Adam Williamson 2020-10-11 00:21:34 UTC
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...

Comment 18 Kamil Páral 2020-10-12 13:39:44 UTC
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)

Comment 19 Jonas Ådahl 2020-10-12 14:47:56 UTC
> 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"?

Comment 20 Adam Williamson 2020-10-12 15:58:49 UTC
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.

Comment 21 Adam Williamson 2020-10-12 16:02:47 UTC
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...

Comment 22 Jonas Ådahl 2020-10-12 16:05:53 UTC
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.

Comment 23 Jonas Ådahl 2020-10-12 16:29:10 UTC
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

Comment 24 Fedora Update System 2020-10-12 18:31:38 UTC
FEDORA-2020-c66310a3b6 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-c66310a3b6

Comment 25 Adam Williamson 2020-10-12 18:32:29 UTC
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?

Comment 26 Fedora Update System 2020-10-12 22:45:34 UTC
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.

Comment 27 Kamil Páral 2020-10-13 08:17:56 UTC
(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 :-)

Comment 28 Fedora Update System 2020-10-14 00:42:12 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.