Bug 325731 - virt-manager abruptly disappears with strange error message
virt-manager abruptly disappears with strange error message
Product: Fedora
Classification: Fedora
Component: gtk-vnc (Show other bugs)
All Linux
low Severity high
: ---
: ---
Assigned To: Daniel Berrange
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2007-10-09 19:34 EDT by Andy Grover
Modified: 2007-11-30 17:12 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-10-10 17:04:15 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
virt-manager.log (2.19 KB, text/plain)
2007-10-10 14:04 EDT, Andy Grover
no flags Details

  None (edit)
Description Andy Grover 2007-10-09 19:34:02 EDT
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

Version-Release number of selected component (if applicable):
rawhide + virt-manager hg repo

How reproducible:

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
Comment 1 Daniel Berrange 2007-10-09 21:12:34 EDT
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

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.
Comment 2 Daniel Berrange 2007-10-09 21:13:15 EDT
Oh the /root/.virt-manager/virt-manager.log file could be useful to me too -
could copy it just after a crash & attach it
Comment 3 Andy Grover 2007-10-10 14:03:56 EDT
(In reply to comment #1)
> BTW, can you confirm that you have  gtk-vnc-0.2.0-3.fc8 installed.

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 ()
Comment 4 Andy Grover 2007-10-10 14:04:47 EDT
Created attachment 222831 [details]
Comment 5 Daniel Berrange 2007-10-10 14:15:50 EDT
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.
Comment 6 Daniel Berrange 2007-10-10 16:43:52 EDT
Ok, this isn't actually virt-manager problem at all. The GTK-VNC widget simply
doesn't reset itself properly when its coroutine exits.
Comment 7 Daniel Berrange 2007-10-10 17:04:15 EDT
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)

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