Messing around with virt-manager code, I added this to make ssh graphical connections fail: diff --git a/virtManager/sshtunnels.py b/virtManager/sshtunnels.py index 8d19ccad..954e6806 100644 --- a/virtManager/sshtunnels.py +++ b/virtManager/sshtunnels.py @@ -233,7 +233,7 @@ def _make_ssh_command(ginfo): if ginfo.gsocket: nc_params = "-U %s" % ginfo.gsocket else: - nc_params = "%s %s" % (ginfo.gaddr, ginfo.gport) + nc_params = "BLAH%s %s" % (ginfo.gaddr, ginfo.gport) nc_cmd = ( """nc -q 2>&1 | grep "requires an argument" >/dev/null;""" But with f28 and rawhide gtk-vnc, virt-manager crashes. AFAICT the only relevant chunk of the backtrace is: Thread 1 (Thread 0x7ffff7fd1540 (LWP 20435)): #0 0x00007fff9f79752a in coroutine_yieldto (to=0x5f5f5f5f5f5f5f5f, arg=0x0) at coroutine_ucontext.c:113 #1 0x00007fff9f78dd7a in g_io_wakeup (wait=<optimized out>, wait=<optimized out>) at vncconnection.c:354 #2 0x00007fff9f78dd9d in g_io_wakeup (wait=<optimized out>, wait=<optimized out>) at vncconnection.c:364 #3 0x00007fff9f78dd9d in vnc_connection_timeout (data=<optimized out>) at vncconnection.c:362 #4 0x00007fffe9330371 in g_timeout_dispatch () at /lib64/libglib-2.0.so.0 #5 0x00007fffe932f8ad in g_main_context_dispatch () at /lib64/libglib-2.0.so.0 #6 0x00007fffe932fc78 in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0 #7 0x00007fffe932fd10 in g_main_context_iteration () at /lib64/libglib-2.0.so.0 #8 0x00007fffe8bd8675 in g_application_run () at /lib64/libgio-2.0.so.0 #9 0x00007fffe90e003e in ffi_call_unix64 () at /lib64/libffi.so.6 #10 0x00007fffe90df9ff in ffi_call () at /lib64/libffi.so.6 #11 0x00007fffe9ab0c4d in pygi_invoke_c_callable () at /usr/lib64/python3.6/site-packages/gi/_gi.cpython-36m-x86_64-linux-gnu.so Everything else is basically idle in virt-manager when this crashes so I suspect it's gtk-vnc, but I didn't dig too deeply
Yes, I've found the cause. We schedule a timer to handle stuck connection initialization. In this case the tunnel has failed and so we've cleaned up the connection, but then jumped over the code whiich removes the timer. So the timer fires a few seconds later and touches free'd memory, kaboom.
commit 06a27a4fb52653b4cbf67b75b8116cf6692b435d (HEAD -> master, origin/master, origin/HEAD) Author: Daniel P. Berrangé <berrange> Date: Fri Aug 24 17:18:04 2018 +0100 fix crash when connection fails early When reading the initial greeting a timer is set in the background. If the connection fails early, we can jump to cleanup code before the timer is disable. The timer will later fire, read a coroutine context from freed memory, and likely jump to somewhere awful with predictably crashy results. https://bugzilla.redhat.com/show_bug.cgi?id=1620203 Signed-off-by: Daniel P. Berrangé <berrange>
gtk-vnc-0.7.2-2.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-ca3e0be7e0
mingw-gtk-vnc-0.7.2-2.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-81f007eff6
gtk-vnc-0.7.2-2.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-ca3e0be7e0
mingw-gtk-vnc-0.7.2-2.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-81f007eff6
gtk-vnc-0.7.2-2.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.
mingw-gtk-vnc-0.7.2-2.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.