Red Hat Bugzilla – Bug 325731
virt-manager abruptly disappears with strange error message
Last modified: 2007-11-30 17:12:18 EST
Description of problem: While using virt-manager, sometimes all windows close. I ran virt-manager with --no-fork option and when it disappears I get this message: Co-routine is re-entering itself Aborted Version-Release number of selected component (if applicable): rawhide + virt-manager hg repo How reproducible: 100% Steps to Reproduce: I am using a HVM Windows server 2003 guest. after this is started, opening and closing the guest graphical console a few times seems to trigger this. Let me know what additional info you need. Thanks -- Andy
Ok, the message is that GTK-VNC has detected a bug in the way the VNC console is being used & pre-emptively aborting before more serious memory corruption occurrs. In theory this allows us to get an accurate stack trace showing the root cause of the problem... this ticket will be a useful confirmation of that theory. I'll try and reproduce it myself, but it would be helpful if you could try and get a core dump & stack trace from it. To do this enable the 'development-debuginfo' YUM repository, and install the 'gtk-vnc-debuginfo', 'gtk2-debuginfo','glib2-debuginfo' packages. Finally set 'ulimit -c unlimited' and run virt-manager. When it crashes it should generate a core file in your working directory. Running 'gdb python core.{PID}' and typing 'thread apply all backtrace' should print out a nice long stack trace. BTW, can you confirm that you have gtk-vnc-0.2.0-3.fc8 installed.
Oh the /root/.virt-manager/virt-manager.log file could be useful to me too - could copy it just after a crash & attach it
(In reply to comment #1) > BTW, can you confirm that you have gtk-vnc-0.2.0-3.fc8 installed. Yes. OK hope this means something to you: Thread 1 (process 6542): #0 0x0035c402 in __kernel_vsyscall () #1 0x00c62840 in *__GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #2 0x00c64211 in *__GI_abort () at abort.c:88 #3 0x0061dd6a in yieldto (to=0x94ca2a8, arg=0x94ca210) at coroutine.c:97 #4 0x00626840 in do_vnc_display_open (data=0x94ca210) at vncdisplay.c:731 #5 0x0672b531 in g_idle_dispatch (source=0x94117f0, callback=0x6, user_data=0x94ca210) at gmain.c:4132 #6 0x0672d0fc in IA__g_main_context_dispatch (context=0x8ed6428) at gmain.c:2061 #7 0x0673053f in g_main_context_iterate (context=0x8ed6428, block=1, dispatch=1, self=0x8ed5ad8) at gmain.c:2694 #8 0x067308e9 in IA__g_main_loop_run (loop=0x93bb2a8) at gmain.c:2898 #9 0x06d129a4 in IA__gtk_main () at gtkmain.c:1144 #10 0x00f61e40 in ?? () from /usr/lib/python2.5/site-packages/gtk-2.0/gtk/_gtk.so #11 0x073562cf in PyEval_EvalFrameEx () from /usr/lib/libpython2.5.so.1.0 #12 0x07355bdc in PyEval_EvalFrameEx () from /usr/lib/libpython2.5.so.1.0 #13 0x073572af in PyEval_EvalCodeEx () from /usr/lib/libpython2.5.so.1.0 #14 0x07357333 in PyEval_EvalCode () from /usr/lib/libpython2.5.so.1.0 #15 0x07371066 in ?? () from /usr/lib/libpython2.5.so.1.0 #16 0x0737111e in PyRun_FileExFlags () from /usr/lib/libpython2.5.so.1.0 #17 0x073727d8 in PyRun_SimpleFileExFlags () from /usr/lib/libpython2.5.so.1.0 #18 0x07372f3a in PyRun_AnyFileExFlags () from /usr/lib/libpython2.5.so.1.0 #19 0x0737caf7 in Py_Main () from /usr/lib/libpython2.5.so.1.0 #20 0x080485d2 in main ()
Created attachment 222831 [details] virt-manager.log
Yep, that's very helpful. So it looks like virt-manager is not closing the existing VNC connection correctly, and then trying to open it again. GTK-VNC also seems to be failing to notice it is already open the second time. Both bugs conspire to result in the crash.
Ok, this isn't actually virt-manager problem at all. The GTK-VNC widget simply doesn't reset itself properly when its coroutine exits.
Built gtk-vnc-0.2.0-4.fc8 in rawhide to fix this crash.... * Thu Oct 10 2007 Daniel P. Berrange <berrange@redhat.com> - 0.2.0-4.fc8 - Fixed coroutine cleanup to avoid SEGV (rhbz #325731)