Bug 325731 - virt-manager abruptly disappears with strange error message
Summary: virt-manager abruptly disappears with strange error message
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: gtk-vnc
Version: rawhide
Hardware: All
OS: Linux
low
high
Target Milestone: ---
Assignee: Daniel Berrangé
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-10-09 23:34 UTC by Andy Grover
Modified: 2007-11-30 22:12 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2007-10-10 21:04:15 UTC
Type: ---
Embargoed:


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

Description Andy Grover 2007-10-09 23:34:02 UTC
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

Comment 1 Daniel Berrangé 2007-10-10 01:12:34 UTC
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.


Comment 2 Daniel Berrangé 2007-10-10 01:13:15 UTC
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 18:03:56 UTC
(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 ()


Comment 4 Andy Grover 2007-10-10 18:04:47 UTC
Created attachment 222831 [details]
virt-manager.log

Comment 5 Daniel Berrangé 2007-10-10 18:15:50 UTC
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 Berrangé 2007-10-10 20:43:52 UTC
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 Berrangé 2007-10-10 21:04:15 UTC
Built gtk-vnc-0.2.0-4.fc8  in rawhide to fix this crash....

* Thu Oct 10 2007 Daniel P. Berrange <berrange> - 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.