Created attachment 1696021 [details] Contents of /var/spool/abrt/ccpp-2020-06-08-09:38:23.998277-3045 Description of problem: gnome-remote-desktop crashes upon VNC connection. Version-Release number of selected component (if applicable): gnome-remote-desktop-0.1.8-2.fc32.x86_64 How reproducible: Always Steps to Reproduce: 1. On server, enable "screen sharing" in Gnome settings. 2. On client (I've tested boxes and remmina), attempt to remote control server. Actual results: gnome-remote-desktop core dumps Expected results: Remote control of server from client. Additional info: Both server and client are running Fedora 32 (Gnome / Wayland), with all the latest updates, and are on the same local network. With the previous package installed: gnome-remote-desktop-0.1.8-1.fc32.x86_64 the journal would be flooded with the following messages, but remote desktop worked: Jun 08 09:41:46 server gnome-shell[2656]: cogl_texture_2d_new_with_size: assertion 'width >= 1' failed Jun 08 09:41:46 server gnome-shell[2656]: Failed to capture stage: Failed to create 0x0 texture Upon connection the journal now shows: Jun 08 16:35:41 localhost.localdomain systemd-coredump[2702]: Process 2540 (gnome-remote-de) of user 1001 dumped core. Stack trace of thread 2696: #0 0x00007fb7802f70a8 __memcpy_sse2_unaligned_erms (libc.so.6 + 0xaa0a8) #1 0x000056418129cb19 on_stream_process (gnome-remote-desktop-daemon + 0x19b19) #2 0x00007fb780749c08 call_process (libpipewire-0.3.so.0 + 0x54c08) #3 0x00007fb78074c7e2 impl_node_process_input (libpipewire-0.3.so.0 + 0x577e2) #4 0x00007fb78073c059 process_node (libpipewire-0.3.so.0 + 0x47059) #5 0x00007fb78073a9dc node_on_fd_events (libpipewire-0.3.so.0 + 0x459dc) #6 0x00007fb77d01bfdc loop_iterate (libspa-support.so + 0x4fdc) #7 0x00007fb780723227 do_loop (libpipewire-0.3.so.0 + 0x2e227) #8 0x00007fb7801bb432 start_thread (libpthread.so.0 + 0x9432) #9 0x00007fb78034e9d3 __clone (libc.so.6 + 0x1019d3) Stack trace of thread 2541: #0 0x00007fb780343b6f __poll (libc.so.6 + 0xf6b6f) #1 0x00007fb780a22ace g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0x52ace) #2 0x00007fb780a22c03 g_main_context_iteration (libglib-2.0.so.0 + 0x52c03) #3 0x00007fb780a22c51 glib_worker_main (libglib-2.0.so.0 + 0x52c51) #4 0x00007fb780a4c812 g_thread_proxy (libglib-2.0.so.0 + 0x7c812) #5 0x00007fb7801bb432 start_thread (libpthread.so.0 + 0x9432) #6 0x00007fb78034e9d3 __clone (libc.so.6 + 0x1019d3) Stack trace of thread 2543: #0 0x00007fb780343b6f __poll (libc.so.6 + 0xf6b6f) #1 0x00007fb780a22ace g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0x52ace) #2 0x00007fb780a22e53 g_main_loop_run (libglib-2.0.so.0 + 0x52e53) #3 0x00007fb78090e6aa gdbus_shared_thread_func (libgio-2.0.so.0 + 0x1226aa) #4 0x00007fb780a4c812 g_thread_proxy (libglib-2.0.so.0 + 0x7c812) #5 0x00007fb7801bb432 start_thread (libpthread.so.0 + 0x9432) #6 0x00007fb78034e9d3 __clone (libc.so.6 + 0x1019d3) Stack trace of thread 2686: #0 0x00007fb78034943d syscall (libc.so.6 + 0xfc43d) #1 0x00007fb780a71426 g_cond_wait_until (libglib-2.0.so.0 + 0xa1426) #2 0x00007fb7809f24c1 g_async_queue_pop_intern_unlocked (libglib-2.0.so.0 + 0x224c1) #3 0x00007fb7809f2b06 g_async_queue_timeout_pop (libglib-2.0.so.0 + 0x22b06) #4 0x00007fb780a4d1b9 g_thread_pool_thread_proxy (libglib-2.0.so.0 + 0x7d1b9) #5 0x00007fb780a4c812 g_thread_proxy (libglib-2.0.so.0 + 0x7c812) #6 0x00007fb7801bb432 start_thread (libpthread.so.0 + 0x9432) #7 0x00007fb78034e9d3 __clone (libc.so.6 + 0x1019d3) Stack trace of thread 2542: #0 0x00007fb780343b6f __poll (libc.so.6 + 0xf6b6f) #1 0x00007fb780a22ace g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0x52ace) #2 0x00007fb780a22c03 g_main_context_iteration (libglib-2.0.so.0 + 0x52c03) #3 0x00007fb77f833fbd dconf_gdbus_worker_thread (libdconfsettings.so + 0xafbd) #4 0x00007fb780a4c812 g_thread_proxy (libglib-2.0.so.0 + 0x7c812) #5 0x00007fb7801bb432 start_thread (libpthread.so.0 + 0x9432) #6 0x00007fb78034e9d3 __clone (libc.so.6 + 0x1019d3) Stack trace of thread 2540: #0 0x00007fb780343b6f __poll (libc.so.6 + 0xf6b6f) #1 0x00007fb780a22ace g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0x52ace) #2 0x00007fb780a22c03 g_main_context_iteration (libglib-2.0.so.0 + 0x52c03) #3 0x00007fb7808d172d g_application_run (libgio-2.0.so.0 + 0xe572d) #4 0x000056418128c6e8 main (gnome-remote-desktop-daemon + 0x96e8) #5 0x00007fb780274042 __libc_start_main (libc.so.6 + 0x27042) #6 0x000056418128c7de _start (gnome-remote-desktop-daemon + 0x97de) Attached is the info captured by abrt-server. Let me know if you need any additional information.
Created attachment 1696139 [details] Contents of /var/spool/abrt/ccpp-2020-06-08-16:35:41.29468-2540/
Replaced details and attachment with those from a fresh build with no modifications.
Hello, I also have crashes with gnome-remote using "physical" machines. Server is running: fedora 32, gnome/wayland, graphical card is an AMD RX570 using mesa drivers, cpu is a Ryzen 5 2600. Client uses Remminna for connecting. Versions of : - gnome-remote-desktop: 0.1.8 - pipewire: 0.3.5 The errors I got are the following: Storage: /var/lib/systemd/coredump/core.gnome-remote-de.1000.249f4fd1d0514e27b8654d6504aefe63.2911.1591876469000000000000.lz4 Message: Process 2911 (gnome-remote-de) of user 1000 dumped core. Stack trace of thread 12729: #0 0x00007fce19047735 __memmove_avx_unaligned_erms (libc.so.6 + 0x165735) #1 0x000056146f31bb19 on_stream_process (gnome-remote-desktop-daemon + 0x19b19) #2 0x00007fce193dec08 call_process (libpipewire-0.3.so.0 + 0x54c08) #3 0x00007fce193e17e2 impl_node_process_input (libpipewire-0.3.so.0 + 0x577e2) #4 0x00007fce193d1059 process_node (libpipewire-0.3.so.0 + 0x47059) #5 0x00007fce193cf9dc node_on_fd_events (libpipewire-0.3.so.0 + 0x459dc) #6 0x00007fce15abafdc loop_iterate (libspa-support.so + 0x4fdc) #7 0x00007fce193b8227 do_loop (libpipewire-0.3.so.0 + 0x2e227) #8 0x00007fce18e50432 start_thread (libpthread.so.0 + 0x9432) #9 0x00007fce18fe39d3 __clone (libc.so.6 + 0x1019d3) Stack trace of thread 2911: #0 0x00007fce18fd8b6f __poll (libc.so.6 + 0xf6b6f) #1 0x00007fce196b7ace g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0x52ace) #2 0x00007fce196b7c03 g_main_context_iteration (libglib-2.0.so.0 + 0x52c03) #3 0x00007fce1956672d g_application_run (libgio-2.0.so.0 + 0xe572d) #4 0x000056146f30b6e8 main (gnome-remote-desktop-daemon + 0x96e8) #5 0x00007fce18f09042 __libc_start_main (libc.so.6 + 0x27042) #6 0x000056146f30b7de _start (gnome-remote-desktop-daemon + 0x97de) Stack trace of thread 2917: #0 0x00007fce18fd8b6f __poll (libc.so.6 + 0xf6b6f) #1 0x00007fce196b7ace g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0x52ace) #2 0x00007fce196b7c03 g_main_context_iteration (libglib-2.0.so.0 + 0x52c03) #3 0x00007fce196b7c51 glib_worker_main (libglib-2.0.so.0 + 0x52c51) #4 0x00007fce196e1812 g_thread_proxy (libglib-2.0.so.0 + 0x7c812) #5 0x00007fce18e50432 start_thread (libpthread.so.0 + 0x9432) #6 0x00007fce18fe39d3 __clone (libc.so.6 + 0x1019d3) Stack trace of thread 12721: #0 0x00007fce18fde43d syscall (libc.so.6 + 0xfc43d) #1 0x00007fce19706426 g_cond_wait_until (libglib-2.0.so.0 + 0xa1426) #2 0x00007fce196874c1 g_async_queue_pop_intern_unlocked (libglib-2.0.so.0 + 0x224c1) #3 0x00007fce19687b06 g_async_queue_timeout_pop (libglib-2.0.so.0 + 0x22b06) #4 0x00007fce196e21b9 g_thread_pool_thread_proxy (libglib-2.0.so.0 + 0x7d1b9) #5 0x00007fce196e1812 g_thread_proxy (libglib-2.0.so.0 + 0x7c812) #6 0x00007fce18e50432 start_thread (libpthread.so.0 + 0x9432) #7 0x00007fce18fe39d3 __clone (libc.so.6 + 0x1019d3) Stack trace of thread 2920: #0 0x00007fce18fd8b6f __poll (libc.so.6 + 0xf6b6f) #1 0x00007fce196b7ace g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0x52ace) #2 0x00007fce196b7e53 g_main_loop_run (libglib-2.0.so.0 + 0x52e53) #3 0x00007fce195a36aa gdbus_shared_thread_func (libgio-2.0.so.0 + 0x1226aa) #4 0x00007fce196e1812 g_thread_proxy (libglib-2.0.so.0 + 0x7c812) #5 0x00007fce18e50432 start_thread (libpthread.so.0 + 0x9432) #6 0x00007fce18fe39d3 __clone (libc.so.6 + 0x1019d3) Stack trace of thread 2918: #0 0x00007fce18fd8b6f __poll (libc.so.6 + 0xf6b6f) #1 0x00007fce196b7ace g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0x52ace) #2 0x00007fce196b7c03 g_main_context_iteration (libglib-2.0.so.0 + 0x52c03) #3 0x00007fce197b3fbd dconf_gdbus_worker_thread (libdconfsettings.so + 0xafbd) #4 0x00007fce196e1812 g_thread_proxy (libglib-2.0.so.0 + 0x7c812) #5 0x00007fce18e50432 start_thread (libpthread.so.0 + 0x9432) #6 0x00007fce18fe39d3 __clone (libc.so.6 + 0x1019d3) Process 2905 (gnome-remote-desktop-daemon) crashed in __memmove_avx_unaligned_erms() If more informations are requires, I will provide them.
After upgrading to mesa 20.1.1 and pipewire 0.3.6, it seems it doesnt crash anymore
I confirm that the application does not crash following the latest updates. The responses are very slow for two systems on the same network. The journal on the host is flooded with messages every second such as the following: Jun 22 17:58:50 localhost.localdomain gnome-remote-desktop-daemon[2966]: [W][000202324.181725][impl-node.c:967 node_on_fd_events()] node 0x55a1932e70c0: missed 6 wakeups Jun 22 17:58:50 localhost.localdomain gnome-remote-desktop-daemon[2966]: [W][000202324.689611][impl-node.c:967 node_on_fd_events()] node 0x55a1932e70c0: missed 8 wakeups Jun 22 17:58:51 localhost.localdomain gnome-remote-desktop-daemon[2966]: [W][000202325.196572][impl-node.c:967 node_on_fd_events()] node 0x55a1932e70c0: missed 3 wakeups Jun 22 17:58:51 localhost.localdomain pipewire[216721]: [W][000202325.326265][private.h:73 ratelimit_test()] 26 events suppressed Jun 22 17:58:51 localhost.localdomain pipewire[216721]: [W][000202325.326282][impl-node.c:1396 node_ready()] (meta-screen-cast-src-30) graph not finished: state:0x7f9d2a225008 quantum:1024 pending 1/3 Jun 22 17:58:51 localhost.localdomain pipewire[216721]: [W][000202325.326287][impl-node.c:835 dump_states()] (grd-vnc-pipewire-stream-41) state:0x7f9d29f58008 pending:0/2 s:202327123827842 a:202327072480530 f:202327072451106 waiting:18446744073658204304 process:18446744073709522192 status:triggered sync:0 Jun 22 17:58:51 localhost.localdomain pipewire[216721]: [W][000202325.326299][impl-node.c:835 dump_states()] (meta-screen-cast-src-30) state:0x7f9d2a225008 pending:1/3 s:202327202139871 a:202327072550554 f:202327123827479 waiting:18446744073579962299 process:51276925 status:triggered sync:0 Jun 22 17:58:51 localhost.localdomain pipewire[216721]: [W][000202325.326303][impl-node.c:835 dump_states()] (meta-screen-cast-src-30) state:0x7f9d2a225008 pending:1/3 s:202327202139871 a:202327072550554 f:202327123827479 waiting:18446744073579962299 process:51276925 status:triggered sync:0
Following a period of time where VNC sort of worked, with the following installed: gnome-remote-desktop-0.1.8-2.fc32.x86_64 mutter-3.36.4-1.fc32.x86_64 pipewire-0.3.6-1.fc32.x86_64 all attempts to connect now simply hang, irrespective of the client used. There is nothing logged in the journal on either the server or client. I see the following connection apparently being established: gnome-rem 451254 user 9u IPv6 3136203 0t0 TCP *:5900 (LISTEN) gnome-rem 451254 user 10u IPv6 3137793 0t0 TCP 192.168.10.2:5900->192.168.10.3:53258 (ESTABLISHED) and all subsequent connection attempts report "connection closed by remote host". If I restart the gnome-remote-desktop process and try to connect again, the situation repeats itself.
This is occurring here as well. The dumps look like mine too. Remmina instantly disconnects and RealVNC Viewer keeps trying. Occasionally it will connect, but I get a black screen. Fedora 31 works, but Fedora 32 doesn't. Rawhide also has this issue. I tried a lower version of gnome-remote-desktop but that didn't help in my case. I wasn't able to successfully downgrade pipewire to try that.
A fresh install of Rawhide with all updates applied yields the below stack trace when connecting via VNC. I've also included the xdp-remote-desktop.py (https://gitlab.gnome.org/snippets/39) test script results. It doesn't display a window for me to select a monitor to cast. Versions used are: mutter 3.37.90-1.fc34 gnome-remote-desktop 0.1.7-5.fc33 gnome-shell 3.37.90-1.fc34 pipewire 0.3.9-1.fc33 Stack trace of a local connection with GNOME Boxes: Aug 20 22:43:50 localhost.localdomain systemd-coredump[2766]: [🡕] Process 2584 (gnome-remote-de) of user 1000 dumped core. Stack trace of thread 2584: #0 0x00007f2441b8272a rfbMakeRichCursorFromXCursor (libvncserver.so.1 + 0x1f72a) #1 0x00007f2441b87680 rfbSendCursorShape (libvncserver.so.1 + 0x24680) #2 0x00007f2441b79bc0 rfbSendFramebufferUpdate (libvncserver.so.1 + 0x16bc0) #3 0x00007f2441b7a705 rfbUpdateClient (libvncserver.so.1 + 0x17705) #4 0x00007f2441b7d3d0 rfbProcessEvents (libvncserver.so.1 + 0x1a3d0) #5 0x000055ca2b2a16fb vnc_socket_grab_func (gnome-remote-desktop-daemon + 0xd6fb) #6 0x000055ca2b2a17a6 handle_socket_data (gnome-remote-desktop-daemon + 0xd7a6) #7 0x00007f2441d060fb socket_source_dispatch (libgio-2.0.so.0 + 0xa60fb) #8 0x00007f2441e96eaf g_main_context_dispatch (libglib-2.0.so.0 + 0x52eaf) #9 0x00007f2441e97238 g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0x53238) #10 0x00007f2441e97303 g_main_context_iteration (libglib-2.0.so.0 + 0x53303) #11 0x00007f2441d455ad g_application_run (libgio-2.0.so.0 + 0xe55ad) #12 0x000055ca2b29bfca main (gnome-remote-desktop-daemon + 0x7fca) #13 0x00007f24417781a2 __libc_start_main (libc.so.6 + 0x281a2) #14 0x000055ca2b29c0ee _start (gnome-remote-desktop-daemon + 0x80ee) Stack trace of thread 2585: #0 0x00007f2441846a4f __poll (libc.so.6 + 0xf6a4f) #1 0x00007f2441e971ce g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0x531ce) #2 0x00007f2441e97303 g_main_context_iteration (libglib-2.0.so.0 + 0x53303) #3 0x00007f2441e97351 glib_worker_main (libglib-2.0.so.0 + 0x53351) #4 0x00007f2441ec0e82 g_thread_proxy (libglib-2.0.so.0 + 0x7ce82) #5 0x00007f24416be3f9 start_thread (libpthread.so.0 + 0x93f9) #6 0x00007f2441851b43 __clone (libc.so.6 + 0x101b43) Stack trace of thread 2587: #0 0x00007f2441846a4f __poll (libc.so.6 + 0xf6a4f) #1 0x00007f2441e971ce g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0x531ce) #2 0x00007f2441e97303 g_main_context_iteration (libglib-2.0.so.0 + 0x53303) #3 0x00007f244038303d dconf_gdbus_worker_thread (libdconfsettings.so + 0x703d) #4 0x00007f2441ec0e82 g_thread_proxy (libglib-2.0.so.0 + 0x7ce82) #5 0x00007f24416be3f9 start_thread (libpthread.so.0 + 0x93f9) #6 0x00007f2441851b43 __clone (libc.so.6 + 0x101b43) Stack trace of thread 2749: #0 0x00007f244184c54d syscall (libc.so.6 + 0xfc54d) #1 0x00007f2441ee5a96 g_cond_wait_until (libglib-2.0.so.0 + 0xa1a96) #2 0x00007f2441e66541 g_async_queue_pop_intern_unlocked (libglib-2.0.so.0 + 0x22541) #3 0x00007f2441e66b86 g_async_queue_timeout_pop (libglib-2.0.so.0 + 0x22b86) #4 0x00007f2441ec1829 g_thread_pool_thread_proxy (libglib-2.0.so.0 + 0x7d829) #5 0x00007f2441ec0e82 g_thread_proxy (libglib-2.0.so.0 + 0x7ce82) #6 0x00007f24416be3f9 start_thread (libpthread.so.0 + 0x93f9) #7 0x00007f2441851b43 __clone (libc.so.6 + 0x101b43) Stack trace of thread 2761: #0 0x00007f2441851e8e epoll_wait (libc.so.6 + 0x101e8e) #1 0x00007f2440376c9e loop_iterate (libspa-support.so + 0x3c9e) #2 0x00007f2441bd5f88 do_loop (libpipewire-0.2.so.1 + 0xbf88) #3 0x00007f24416be3f9 start_thread (libpthread.so.0 + 0x93f9) #4 0x00007f2441851b43 __clone (libc.so.6 + 0x101b43) Stack trace of thread 2586: #0 0x00007f2441846a4f __poll (libc.so.6 + 0xf6a4f) #1 0x00007f2441e971ce g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0x531ce) #2 0x00007f2441e97553 g_main_loop_run (libglib-2.0.so.0 + 0x53553) #3 0x00007f2441d8250a gdbus_shared_thread_func (libgio-2.0.so.0 + 0x12250a) #4 0x00007f2441ec0e82 g_thread_proxy (libglib-2.0.so.0 + 0x7ce82) #5 0x00007f24416be3f9 start_thread (libpthread.so.0 + 0x93f9) #6 0x00007f2441851b43 __clone (libc.so.6 + 0x101b43) Aug 20 22:43:50 localhost.localdomain systemd[1]: systemd-coredump: Succeeded. Run of xdp-remote-desktop.py: $ python3 xdp-remote-desktop.py /home/ty/Downloads/xdp-remote-desktop.py:13: PyGIDeprecationWarning: Since version 3.11, calling threads_init is no longer needed. See: https://wiki.gnome.org/PyGObject/Threading GObject.threads_init() session /org/freedesktop/portal/desktop/session/1_143/u1 created devices selected Failed to select sources: 2
A fresh installation of Fedora 32 with all updates applied (including pipewire-0.3.10) now matches the initial report's trace (crashing in __memcpy_sse2_unalignt_erms). I can occasionally connect, getting a black screen, but it will segfault after a while. dmesg shows this: [Aug21 20:02] gnome-remote-de[3001]: segfault at 0 ip 00007f0ffb0bb048 sp 00007f0feb7faee8 error 4 in libc-2.31.so[7f0ffb036000+150000] [ +0.000008] Code: 29 4f 10 0f 29 57 20 0f 29 5f 30 48 83 c7 40 48 83 fa 40 77 d0 0f 11 29 0f 11 71 f0 0f 11 79 e0 44 0f 11 41 d0 41 0f 11 23 c3 <0f> 10 26 0f 10 6e 10 0f 10 76 20 0f 10 7e 30 44 0f 10 44 16 f0 4c
can anyone try this scratch build? https://bugzilla.redhat.com/show_bug.cgi?id=1844993
actually, can anyone try this scratch build? https://koji.fedoraproject.org/koji/taskinfo?taskID=50206570
(In reply to Ray Strode [halfline] from comment #11) > actually, can anyone try this scratch build? > https://koji.fedoraproject.org/koji/taskinfo?taskID=50206570 Assuming I installed it right (I'm new to Fedora), I get the same errors as before. I can get an image, but every time I move the mouse it loses the connection and tries to reconnect ("The connection was closed remotely"). Eventually it segfaults. It also seems to segfault sometimes after connecting without moving the mouse.
(In reply to Ray Strode [halfline] from comment #11) > actually, can anyone try this scratch build? > https://koji.fedoraproject.org/koji/taskinfo?taskID=50206570 I applied the scratch build package and have been successfully using Gnome Remote Desktop with Remmina all day. For info. The journal is full of log entries such as the following: Aug 27 18:23:38 localhost.localdomain gnome-remote-desktop-daemon[3068]: [W][000033128.808529][impl-node.c:1010 node_on_fd_events()] node 0x55f387b446e0: missed 5 wakeups Aug 27 18:23:38 localhost.localdomain gnome-remote-desktop-daemon[3068]: [W][000033129.321544][impl-node.c:1010 node_on_fd_events()] node 0x55f387b446e0: missed 7 wakeups Aug 27 18:23:39 localhost.localdomain gnome-remote-desktop-daemon[3068]: [W][000033129.896083][impl-node.c:1010 node_on_fd_events()] node 0x55f387b446e0: missed 3 wakeups Aug 27 18:23:39 localhost.localdomain gnome-remote-desktop-daemon[3068]: [W][000033130.400637][impl-node.c:1010 node_on_fd_events()] node 0x55f387b446e0: missed 5 wakeups Aug 27 18:23:39 localhost.localdomain pipewire[6124]: [W][000033130.628346][private.h:73 ratelimit_test()] 23 events suppressed Aug 27 18:23:39 localhost.localdomain pipewire[6124]: [W][000033130.628367][impl-node.c:1448 node_ready()] (gnome-shell-30) graph not finished: state:0x7fbc90282008 quantum:1024 pending 1/3 Aug 27 18:23:39 localhost.localdomain pipewire[6124]: [W][000033130.628371][impl-node.c:878 dump_states()] (gnome-shell-30) state:0x7fbc90282008 pending:1/3 s:33131575394101 a:33131542303487 f:33131542303883 waiting:18446744073676461002 process:396 status:triggered sync:0 Aug 27 18:23:39 localhost.localdomain pipewire[6124]: [W][000033130.628383][impl-node.c:878 dump_states()] (gnome-shell-30) state:0x7fbc90282008 pending:1/3 s:33131575394101 a:33131542303487 f:33131542303883 waiting:18446744073676461002 process:396 status:triggered sync:0 Aug 27 18:23:39 localhost.localdomain pipewire[6124]: [W][000033130.628386][impl-node.c:878 dump_states()] (gnome-remote-de-35) state:0x7fbc8e2fa008 pending:-1/2 s:33131542294092 a:33131347719636 f:33131347698096 waiting:18446744073514977160 process:18446744073709530076 status:triggered sync:0
(In reply to AM from comment #12) > Assuming I installed it right (I'm new to Fedora), I get the same errors as > before. I can get an image, but every time I move the mouse it loses the > connection and tries to reconnect ("The connection was closed remotely"). > Eventually it segfaults. > > It also seems to segfault sometimes after connecting without moving the > mouse. Probably a different issue. do you have really big cursors? Can you post a stack trace?
FEDORA-2020-6f1c2ac099 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-6f1c2ac099
(In reply to Ray Strode [halfline] from comment #14) > (In reply to AM from comment #12) > > > Assuming I installed it right (I'm new to Fedora), I get the same errors as > > before. I can get an image, but every time I move the mouse it loses the > > connection and tries to reconnect ("The connection was closed remotely"). > > Eventually it segfaults. > > > > It also seems to segfault sometimes after connecting without moving the > > mouse. > > Probably a different issue. do you have really big cursors? Can you post a > stack trace? Sure thing! The cursors are the default size. It could be that I'm trying this in a VM, but it works with Fedora 31. I noticed there's a fork on the GNOME GitLab that fixes some cursor issues (https://gitlab.gnome.org/pnowack/gnome-remote-desktop/-/tree/max_cursor_size_adaptions). That might also be my problem. I'm getting ready to do a fresh bare metal install of 32 and see if there's a difference. i uninstalled gnome-remote-desktop with dnf remove, rebooted, then installed your scratch build with rpm -i. Stack trace: Aug 27 16:51:28 localhost.localdomain systemd-coredump[1752]: Process 1732 (gnome-remote-de) of user 1000 dumped core. Stack trace of thread 1750: #0 0x00007f23db7bf048 __memcpy_sse2_unaligned_erms (libc.so.6 + 0xaa048) #1 0x000055e99521fb22 on_stream_process (gnome-remote-desktop-daemon + 0x19b22) #2 0x00007f23dbc14448 call_process (libpipewire-0.3.so.0 + 0x57448) #3 0x00007f23dbc17092 impl_node_process_input (libpipewire-0.3.so.0 + 0x5a092) #4 0x00007f23dbc065a9 process_node (libpipewire-0.3.so.0 + 0x495a9) #5 0x00007f23dbc04eac node_on_fd_events (libpipewire-0.3.so.0 + 0x47eac) #6 0x00007f23d81edfbc loop_iterate (libspa-support.so + 0x4fbc) #7 0x00007f23dbbecfe7 do_loop (libpipewire-0.3.so.0 + 0x2ffe7) #8 0x00007f23db683432 start_thread (libpthread.so.0 + 0x9432) #9 0x00007f23db816913 __clone (libc.so.6 + 0x101913) Stack trace of thread 1733: #0 0x00007f23db80baaf __poll (libc.so.6 + 0xf6aaf) #1 0x00007f23dbeefaae g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0x52aae) #2 0x00007f23dbeefbe3 g_main_context_iteration (libglib-2.0.so.0 + 0x52be3) #3 0x00007f23dbeefc31 glib_worker_main (libglib-2.0.so.0 + 0x52c31) #4 0x00007f23dbf197f2 g_thread_proxy (libglib-2.0.so.0 + 0x7c7f2) #5 0x00007f23db683432 start_thread (libpthread.so.0 + 0x9432) #6 0x00007f23db816913 __clone (libc.so.6 + 0x101913) Stack trace of thread 1734: #0 0x00007f23db80baaf __poll (libc.so.6 + 0xf6aaf) #1 0x00007f23dbeefaae g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0x52aae) #2 0x00007f23dbeefbe3 g_main_context_iteration (libglib-2.0.so.0 + 0x52be3) #3 0x00007f23dabdafbd dconf_gdbus_worker_thread (libdconfsettings.so + 0xafbd) #4 0x00007f23dbf197f2 g_thread_proxy (libglib-2.0.so.0 + 0x7c7f2) #5 0x00007f23db683432 start_thread (libpthread.so.0 + 0x9432) #6 0x00007f23db816913 __clone (libc.so.6 + 0x101913) Stack trace of thread 1735: #0 0x00007f23db80baaf __poll (libc.so.6 + 0xf6aaf) #1 0x00007f23dbeefaae g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0x52aae) #2 0x00007f23dbeefe33 g_main_loop_run (libglib-2.0.so.0 + 0x52e33) #3 0x00007f23dbddb69a gdbus_shared_thread_func (libgio-2.0.so.0 + 0x12269a) #4 0x00007f23dbf197f2 g_thread_proxy (libglib-2.0.so.0 + 0x7c7f2) #5 0x00007f23db683432 start_thread (libpthread.so.0 + 0x9432) #6 0x00007f23db816913 __clone (libc.so.6 + 0x101913) Stack trace of thread 1737: #0 0x00007f23db81137d syscall (libc.so.6 + 0xfc37d) #1 0x00007f23dbf3e616 g_cond_wait_until (libglib-2.0.so.0 + 0xa1616) #2 0x00007f23dbebf4a1 g_async_queue_pop_intern_unlocked (libglib-2.0.so.0 + 0x224a1) #3 0x00007f23dbf1a24a g_thread_pool_thread_proxy (libglib-2.0.so.0 + 0x7d24a) #4 0x00007f23dbf197f2 g_thread_proxy (libglib-2.0.so.0 + 0x7c7f2) #5 0x00007f23db683432 start_thread (libpthread.so.0 + 0x9432) #6 0x00007f23db816913 __clone (libc.so.6 + 0x101913) Stack trace of thread 1732: #0 0x00007f23dbb63df0 n/a (libvncserver.so.1 + 0xddf0) #1 0x00007f23dbb75163 sendHextiles32 (libvncserver.so.1 + 0x1f163) #2 0x00007f23dbb6c5c9 rfbSendFramebufferUpdate (libvncserver.so.1 + 0x165c9) #3 0x00007f23dbb66b35 rfbUpdateClient (libvncserver.so.1 + 0x10b35) #4 0x00007f23dbb66bb0 rfbProcessEvents (libvncserver.so.1 + 0x10bb0) #5 0x000055e99521f98e do_render (gnome-remote-desktop-daemon + 0x1998e) #6 0x00007f23d81ed7c8 flush_items (libspa-support.so + 0x47c8) #7 0x00007f23d81ed6b2 source_event_func (libspa-support.so + 0x46b2) #8 0x00007f23d81edfbc loop_iterate (libspa-support.so + 0x4fbc) #9 0x000055e99521b45a pipewire_loop_source_dispatch (gnome-remote-desktop-daemon + 0x1545a) #10 0x00007f23dbeef78f g_main_context_dispatch (libglib-2.0.so.0 + 0x5278f) #11 0x00007f23dbeefb18 g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0x52b18) #12 0x00007f23dbeefbe3 g_main_context_iteration (libglib-2.0.so.0 + 0x52be3) #13 0x00007f23dbd9e71d g_application_run (libgio-2.0.so.0 + 0xe571d) #14 0x000055e99520f6e8 main (gnome-remote-desktop-daemon + 0x96e8) #15 0x00007f23db73c042 __libc_start_main (libc.so.6 + 0x27042) #16 0x000055e99520f7de _start (gnome-remote-desktop-daemon + 0x97de) dmesg: [ 85.019742] gnome-remote-de[1362]: segfault at 0 ip 00007fe2c44608ba sp 00007ffcc7a10730 error 4 in libvncserver.so.0.9.13[7fe2c4446000+35000] [ 85.019754] Code: 89 cf 83 c2 01 40 d0 ef 83 e1 01 89 f9 bf 80 ff ff ff 0f 45 cf 48 01 f0 39 da 74 5c 89 d7 41 89 cf c1 ff 03 44 01 d7 48 63 ff <45> 22 3c 3b 75 a0 83 fe 08 0f 83 b7 00 00 00 44 8b 44 24 14 45 85 [ 87.720643] gnome-remote-de[1706]: segfault at 0 ip 00007f909fdc8048 sp 00007f909c9cfee8 error 4 in libc-2.31.so[7f909fd43000+150000] [ 87.720653] Code: 29 4f 10 0f 29 57 20 0f 29 5f 30 48 83 c7 40 48 83 fa 40 77 d0 0f 11 29 0f 11 71 f0 0f 11 79 e0 44 0f 11 41 d0 41 0f 11 23 c3 <0f> 10 26 0f 10 6e 10 0f 10 76 20 0f 10 7e 30 44 0f 10 44 16 f0 4c [ 91.262166] gnome-remote-de[1729]: segfault at 0 ip 00007fd680c4c048 sp 00007fd67d853ee8 error 4 in libc-2.31.so[7fd680bc7000+150000] [ 91.262519] Code: 29 4f 10 0f 29 57 20 0f 29 5f 30 48 83 c7 40 48 83 fa 40 77 d0 0f 11 29 0f 11 71 f0 0f 11 79 e0 44 0f 11 41 d0 41 0f 11 23 c3 <0f> 10 26 0f 10 6e 10 0f 10 76 20 0f 10 7e 30 44 0f 10 44 16 f0 4c [ 95.265326] gnome-remote-de[1750]: segfault at 0 ip 00007f23db7bf048 sp 00007f23cbffbee8 error 4 in libc-2.31.so[7f23db73a000+150000] [ 95.265336] Code: 29 4f 10 0f 29 57 20 0f 29 5f 30 48 83 c7 40 48 83 fa 40 77 d0 0f 11 29 0f 11 71 f0 0f 11 79 e0 44 0f 11 41 d0 41 0f 11 23 c3 <0f> 10 26 0f 10 6e 10 0f 10 76 20 0f 10 7e 30 44 0f 10 44 16 f0 4c t
looks like the same issue indeed, so I moved it back to ASSIGNED
i think i see another issue that might be your problem. can you try this build: Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=50274261 ?
Thank you so much! It works! It doesn’t disconnect now. However, it seems like the mouse is off-centered and jittery in movement. This is only reflected in the VNC window. The actual desktop doesn’t show it. It’s like the VNC session is redrawing previous frames while it draws the new one. As examples: The Activities overview flickers twice when I open it. Dragging a window down makes it snap back up to the top. Moving my mouse while the terminal prompt is open makes the prompt blink faster. Moving the mouse over items in a menu makes it jump between the last highlighted item and the one the mouse is currently over. Once you go past the top or bottom of the menu the last highlighted option will flicker for every other step you move the mouse. Any sort of item that has a hover effect (like the close button) behaves the same. Perhaps most telling is if I move the mouse over the top bar while the time changes it flickers between the previous minute and the current one until I stop moving it for a bit. I’ll attach a screen recording of it because I’m awful at putting stuff into words. The behavior is consistent on both VNC Viewer and Remmina. On connection it blanked out a couple times and shifted the wallpaper but it corrected itself. It crashed once but I’m not sure of the circumstances around it. Also, I like your package names :)
Created attachment 1712899 [details] Screen recording of bug
I've thrown a few backports in, maybe they'll help? Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=50322833
(In reply to Ray Strode [halfline] from comment #21) > I've thrown a few backports in, maybe they'll help? > > Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=50322833 For info. I won't be able to do any more testing until the 7th.
okay i'll just build it as an update, can't make things worse :-)
FEDORA-2020-f82f45c249 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-f82f45c249
You rule! It works now! Thank you so much. I'm sorry, I thought I submitted a comment earlier. I'm having another issue with it not remembering my VNC password but I filed a separate report about that. Again, thank you so much.
FEDORA-2020-f82f45c249 has been pushed to the Fedora 32 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-f82f45c249` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-f82f45c249 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
It worked fine in the VMs I had but it's not working now on my fresh up-to-date F32 installation. I can move the mouse but the VNC screen is black.
Stack trace (If it does crash. It doesn't every time but I get a black screen): Aug 30 17:54:51 localhost.localdomain systemd-coredump[1823]: Process 1404 (gnome-remote-de) of user 1000 dumped core. Stack trace of thread 1404: #0 0x00007f108a79a8ba rfbMakeRichCursorFromXCursor (libvncserver.so.1 + 0x258ba) #1 0x00007f108a79ae20 rfbSendCursorShape (libvncserver.so.1 + 0x25e20) #2 0x00007f108a78b620 rfbSendFramebufferUpdate (libvncserver.so.1 + 0x16620) #3 0x00007f108a785b35 rfbUpdateClient (libvncserver.so.1 + 0x10b35) #4 0x00007f108a785bb0 rfbProcessEvents (libvncserver.so.1 + 0x10bb0) #5 0x000055ff9daf19ab vnc_socket_grab_func (gnome-remote-desktop-daemon + 0x139ab) #6 0x000055ff9daf2725 grd_session_vnc_dispatch (gnome-remote-desktop-daemon + 0x14725) #7 0x000055ff9daf27e6 handle_socket_data (gnome-remote-desktop-daemon + 0x147e6) #8 0x00007f108a97e09b socket_source_dispatch (libgio-2.0.so.0 + 0xa609b) #9 0x00007f108ab0e78f g_main_context_dispatch (libglib-2.0.so.0 + 0x5278f) #10 0x00007f108ab0eb18 g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0x52b18) #11 0x00007f108ab0ebe3 g_main_context_iteration (libglib-2.0.so.0 + 0x52be3) #12 0x00007f108a9bd71d g_application_run (libgio-2.0.so.0 + 0xe571d) #13 0x000055ff9dae76e8 main (gnome-remote-desktop-daemon + 0x96e8) #14 0x00007f108a35b042 __libc_start_main (libc.so.6 + 0x27042) #15 0x000055ff9dae77de _start (gnome-remote-desktop-daemon + 0x97de) Stack trace of thread 1407: #0 0x00007f108a42aaaf __poll (libc.so.6 + 0xf6aaf) #1 0x00007f108ab0eaae g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0x52aae) #2 0x00007f108ab0ebe3 g_main_context_iteration (libglib-2.0.so.0 + 0x52be3) #3 0x00007f108ab0ec31 glib_worker_main (libglib-2.0.so.0 + 0x52c31) #4 0x00007f108ab387f2 g_thread_proxy (libglib-2.0.so.0 + 0x7c7f2) #5 0x00007f108a2a2432 start_thread (libpthread.so.0 + 0x9432) #6 0x00007f108a435913 __clone (libc.so.6 + 0x101913) Stack trace of thread 1812: #0 0x00007f108a43037d syscall (libc.so.6 + 0xfc37d) #1 0x00007f108ab5d616 g_cond_wait_until (libglib-2.0.so.0 + 0xa1616) #2 0x00007f108aade4a1 g_async_queue_pop_intern_unlocked (libglib-2.0.so.0 + 0x224a1) #3 0x00007f108ab3924a g_thread_pool_thread_proxy (libglib-2.0.so.0 + 0x7d24a) #4 0x00007f108ab387f2 g_thread_proxy (libglib-2.0.so.0 + 0x7c7f2) #5 0x00007f108a2a2432 start_thread (libpthread.so.0 + 0x9432) #6 0x00007f108a435913 __clone (libc.so.6 + 0x101913) Stack trace of thread 1409: #0 0x00007f108a42aaaf __poll (libc.so.6 + 0xf6aaf) #1 0x00007f108ab0eaae g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0x52aae) #2 0x00007f108ab0ee33 g_main_loop_run (libglib-2.0.so.0 + 0x52e33) #3 0x00007f108a9fa69a gdbus_shared_thread_func (libgio-2.0.so.0 + 0x12269a) #4 0x00007f108ab387f2 g_thread_proxy (libglib-2.0.so.0 + 0x7c7f2) #5 0x00007f108a2a2432 start_thread (libpthread.so.0 + 0x9432) #6 0x00007f108a435913 __clone (libc.so.6 + 0x101913) Stack trace of thread 1408: #0 0x00007f108a42aaaf __poll (libc.so.6 + 0xf6aaf) #1 0x00007f108ab0eaae g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0x52aae) #2 0x00007f108ab0ebe3 g_main_context_iteration (libglib-2.0.so.0 + 0x52be3) #3 0x00007f10897f9fbd dconf_gdbus_worker_thread (libdconfsettings.so + 0xafbd) #4 0x00007f108ab387f2 g_thread_proxy (libglib-2.0.so.0 + 0x7c7f2) #5 0x00007f108a2a2432 start_thread (libpthread.so.0 + 0x9432) #6 0x00007f108a435913 __clone (libc.so.6 + 0x101913) Stack trace of thread 1821: #0 0x00007f108a435c5e epoll_wait (libc.so.6 + 0x101c5e) #1 0x00007f10887e7518 impl_pollfd_wait (libspa-support.so + 0x7518) #2 0x00007f10887e4f20 loop_iterate (libspa-support.so + 0x4f20) #3 0x00007f108a80bfe7 do_loop (libpipewire-0.3.so.0 + 0x2ffe7) #4 0x00007f108a2a2432 start_thread (libpthread.so.0 + 0x9432) #5 0x00007f108a435913 __clone (libc.so.6 + 0x101913) Aug 30 17:54:51 localhost.localdomain systemd[1]: systemd-coredump: Succeeded. dmesg: [ +0.000007] gnome-remote-de[1404]: segfault at 0 ip 00007f108a79a8ba sp 00007ffeb60564d0 error 4 in libvncserver.so.0.9.13[7f108a780000+35000] [ +0.000018] Code: 89 cf 83 c2 01 40 d0 ef 83 e1 01 89 f9 bf 80 ff ff ff 0f 45 cf 48 01 f0 39 da 74 5c 89 d7 41 89 cf c1 ff 03 44 01 d7 48 63 ff <45> 22 3c 3b 75 a0 83 fe 08 0f 83 b7 00 00 00 44 8b 44 24 14 45 85 Also, while connected, I get a bunch of these in journalctl: Aug 30 18:03:28 localhost.localdomain gnome-remote-de[1832]: Could not map dma-buf: Function not implemented
In the F32 VM on VirtualBox, the only upgraded packages are pipewire to 0.3.10 and gnome-remote-desktop to 0.1.8-4. It works fine. On a physical laptop (not the same machine the above logs are from) I can run the live desktop, upgrade just these two packages, and it doesn’t work.
I tried the live image on my desktop again. Updated only pipewire and gnome-remote-desktop. I can occasionally connect locally with Boxes, but sometimes it crashes or I get a black screen. I always get a black screen or a crash when connecting from mobile devices. Interestingly, the trace now is different from the others posted here: Aug 31 14:12:54 localhost-live systemd-coredump[6416]: Process 6407 (gnome-remote-de) of user 1000 dumped core. Stack trace of thread 6414: #0 0x00007f92398e1a25 raise (libc.so.6 + 0x3ca25) #1 0x00007f92398ca895 abort (libc.so.6 + 0x25895) #2 0x00007f923a043b8c g_assertion_message.cold (libglib-2.0.so.0 + 0x1db8c) #3 0x00007f923a0a184f g_assertion_message_expr (libglib-2.0.so.0 + 0x7b84f) #4 0x000055a51e769d2e on_stream_process (gnome-remote-desktop-daemon + 0x19d2e) #5 0x00007f9239d9d448 call_process (libpipewire-0.3.so.0 + 0x57448) #6 0x00007f9239da0092 impl_node_process_input (libpipewire-0.3.so.0 + 0x5a092) #7 0x00007f9239d8f5a9 process_node (libpipewire-0.3.so.0 + 0x495a9) #8 0x00007f9239d8deac node_on_fd_events (libpipewire-0.3.so.0 + 0x47eac) #9 0x00007f923649efbc loop_iterate (libspa-support.so + 0x4fbc) #10 0x00007f9239d75fe7 do_loop (libpipewire-0.3.so.0 + 0x2ffe7) #11 0x00007f9239813432 start_thread (libpthread.so.0 + 0x9432) #12 0x00007f92399a69d3 __clone (libc.so.6 + 0x1019d3) Stack trace of thread 6408: #0 0x00007f923999bb6f __poll (libc.so.6 + 0xf6b6f) #1 0x00007f923a078a8d g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0x52a8d) #2 0x00007f923a078bc3 g_main_context_iteration (libglib-2.0.so.0 + 0x52bc3) #3 0x00007f923a078c11 glib_worker_main (libglib-2.0.so.0 + 0x52c11) #4 0x00007f923a0a2652 g_thread_proxy (libglib-2.0.so.0 + 0x7c652) #5 0x00007f9239813432 start_thread (libpthread.so.0 + 0x9432) #6 0x00007f92399a69d3 __clone (libc.so.6 + 0x1019d3) Stack trace of thread 6411: #0 0x00007f92399a143d syscall (libc.so.6 + 0xfc43d) #1 0x00007f923a0c7347 g_cond_wait_until (libglib-2.0.so.0 + 0xa1347) #2 0x00007f923a048511 g_async_queue_pop_intern_unlocked (libglib-2.0.so.0 + 0x22511) #3 0x00007f923a048b56 g_async_queue_timeout_pop (libglib-2.0.so.0 + 0x22b56) #4 0x00007f923a0a3001 g_thread_pool_thread_proxy (libglib-2.0.so.0 + 0x7d001) #5 0x00007f923a0a2652 g_thread_proxy (libglib-2.0.so.0 + 0x7c652) #6 0x00007f9239813432 start_thread (libpthread.so.0 + 0x9432) #7 0x00007f92399a69d3 __clone (libc.so.6 + 0x1019d3) Stack trace of thread 6409: #0 0x00007f923999bb6f __poll (libc.so.6 + 0xf6b6f) #1 0x00007f923a078a8d g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0x52a8d) #2 0x00007f923a078bc3 g_main_context_iteration (libglib-2.0.so.0 + 0x52bc3) #3 0x00007f9238e8bfbd dconf_gdbus_worker_thread (libdconfsettings.so + 0xafbd) #4 0x00007f923a0a2652 g_thread_proxy (libglib-2.0.so.0 + 0x7c652) #5 0x00007f9239813432 start_thread (libpthread.so.0 + 0x9432) #6 0x00007f92399a69d3 __clone (libc.so.6 + 0x1019d3) Stack trace of thread 6407: #0 0x00007f923999bb6f __poll (libc.so.6 + 0xf6b6f) #1 0x00007f923a078a8d g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0x52a8d) #2 0x00007f923a078bc3 g_main_context_iteration (libglib-2.0.so.0 + 0x52bc3) #3 0x00007f9239f2786d g_application_run (libgio-2.0.so.0 + 0xe586d) #4 0x000055a51e7596e8 main (gnome-remote-desktop-daemon + 0x96e8) #5 0x00007f92398cc042 __libc_start_main (libc.so.6 + 0x27042) #6 0x000055a51e7597de _start (gnome-remote-desktop-daemon + 0x97de) Stack trace of thread 6410: #0 0x00007f923999bb6f __poll (libc.so.6 + 0xf6b6f) #1 0x00007f923a078a8d g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0x52a8d) #2 0x00007f923a078e0b g_main_loop_run (libglib-2.0.so.0 + 0x52e0b) #3 0x00007f9239f647ea gdbus_shared_thread_func (libgio-2.0.so.0 + 0x1227ea) #4 0x00007f923a0a2652 g_thread_proxy (libglib-2.0.so.0 + 0x7c652) #5 0x00007f9239813432 start_thread (libpthread.so.0 + 0x9432) #6 0x00007f92399a69d3 __clone (libc.so.6 + 0x1019d3) Aug 31 14:12:54 localhost-live systemd[1]: systemd-coredump: Succeeded.
are you using nouveau per chance? i'm just noodling around the kernel source tree, and I see this: int drm_gem_dmabuf_mmap(struct dma_buf *dma_buf, struct vm_area_struct *vma)• {• → struct drm_gem_object *obj = dma_buf->priv;• → struct drm_device *dev = obj->dev;• • → if (!dev->driver->gem_prime_mmap)• → → return -ENOSYS;• • → return dev->driver->gem_prime_mmap(obj, vma);• }• Note, ENOSYS means "Function not implemented" (from your log). So this could be where the error is coming from. Doing ╎❯ git grep gem_prime_mmap I see the virt drivers have it: virtio/virtgpu_drv.c: .gem_prime_mmap = virtgpu_gem_prime_mmap, qxl/qxl_drv.c: .gem_prime_mmap = qxl_gem_prime_mmap, and amd has it too: amd/amdgpu/amdgpu_drv.c: .gem_prime_mmap = amdgpu_gem_prime_mmap, intel, seems special, it does things its own way, using its own function i915_gem_dmabuf_mmap, instead of drm_gem_dmabuf_mmap: static const struct dma_buf_ops i915_dmabuf_ops = {• .. → .mmap = i915_gem_dmabuf_mmap,• .. } but (unless i'm missing something, which is possible), nouveau seems to not implement it at all. in nouveau_drm it sets up → .gem_prime_export = drm_gem_prime_export,• which does: struct dma_buf *drm_gem_prime_export(struct drm_device *dev,• → → → → struct drm_gem_object *obj,• → → → → int flags)• {• → struct dma_buf_export_info exp_info = {• → → .exp_name = KBUILD_MODNAME, /* white lie for debug */• → → .owner = dev->driver->fops->owner,• → → .ops = &drm_gem_prime_dmabuf_ops,• ... }• and drm_gem_prime_dmabuf_ops sets → .mmap = drm_gem_dmabuf_mmap,• (mentioned at the top of this comment). Seems like it's missing a .gem_prime_mmap = nouveau_gem_prime_mmap function or similar.
just googling for nouveau_gem_prime_mmap, shows someone from nvidia sent a patch at some point: https://lists.freedesktop.org/archives/dri-devel/2018-January/162193.html not sure what the story with it is.
Heya, sorry for so many comments on this issue. I just want to help get it fixed. Good catch! As far as I know I'm not using nouveau. The card in my desktop is an old Radeon HD 6570 which I believe uses the radeon driver set. The laptop I mentioned is Kaby Lake Intel integrated. I've been able to connect to my desktop today. I reinstalled F32 and I was able to connect once right after the installation with no updates. After that, I had to install your package and update pipewire or I would get a black screen. I'm not getting those messages on connection now. The only thing different between yesterday and now is I haven't updated anything at all except pipewire and gnome-remote-desktop. Yesterday I had installed all updated packages, which included a new kernel version. Maybe that's something to lead from. I noticed a minor bug with mouseover highlighting while connected, but I can file that separately.
If you could try installing the newest kernel and confirm it fails with newer one, but then try choosing the older one in grub and confirm it makes it work again, that would be great.
Just updated to 5.8.4 from 5.6.6 using sudo dnf update kernel. It seems fine.
interesting. what does rpm -qa |grep mesa say?
mesa-libGL-20.0.4-1.fc32.i686 mesa-vulkan-drivers-20.0.4-1.fc32.x86_64 mesa-vulkan-drivers-20.0.4-1.fc32.i686 mesa-libgbm-20.0.4-1.fc32.x86_64 mesa-dri-drivers-20.0.4-1.fc32.i686 mesa-libEGL-20.0.4-1.fc32.x86_64 mesa-libOSMesa-20.0.4-1.fc32.x86_64 mesa-filesystem-20.0.4-1.fc32.x86_64 mesa-filesystem-20.0.4-1.fc32.i686 mesa-libglapi-20.0.4-1.fc32.x86_64 mesa-libglapi-20.0.4-1.fc32.i686 mesa-libxatracker-20.0.4-1.fc32.x86_64 mesa-dri-drivers-20.0.4-1.fc32.x86_64 mesa-libGL-20.0.4-1.fc32.x86_64
and does updating mesa break it?
Aha! Yes it does. I can still connect but the screen is black. After the update: mesa-filesystem-20.1.6-1.fc32.i686 mesa-libglapi-20.1.6-1.fc32.x86_64 mesa-vulkan-drivers-20.1.6-1.fc32.i686 mesa-libxatracker-20.1.6-1.fc32.x86_64 mesa-libGL-20.1.6-1.fc32.x86_64 mesa-libglapi-20.1.6-1.fc32.i686 mesa-libGL-20.1.6-1.fc32.i686 mesa-libgbm-20.1.6-1.fc32.x86_64 mesa-vulkan-drivers-20.1.6-1.fc32.x86_64 mesa-libEGL-20.1.6-1.fc32.x86_64 mesa-dri-drivers-20.1.6-1.fc32.i686 mesa-libOSMesa-20.1.6-1.fc32.x86_64 mesa-dri-drivers-20.1.6-1.fc32.x86_64 mesa-filesystem-20.1.6-1.fc32.x86_64
I confirmed this by downgrading them, and now I have access again.
i don't really have time to work on this anymore atm, but i re-noticed this bug when I was closing open tabs, so I figured I should chime in one more time... As mentioned earlier, gnome-remote-desktop is doing a mmap and copy, this is seemingly poorly supported (and worse with newer libgbm? something in mesa anyway). At the end of the day, this isn't the best way to get the pixels out, I think. probably the code should be changed to use gbm_bo_import / gbm_bo_map or glReadPixels.
FEDORA-2020-f82f45c249 has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report.