This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 458522 - Connection to KVM/QEMU fails
Connection to KVM/QEMU fails
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: pygobject2 (Show other bugs)
10
All Linux
medium Severity medium
: ---
: ---
Assigned To: Matthew Barnes
Fedora Extras Quality Assurance
:
: 459668 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-08-09 07:43 EDT by Adam Huffman
Modified: 2013-01-09 23:46 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-11-18 08:43:50 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Set threads_enable flag (509 bytes, patch)
2008-08-11 12:27 EDT, Daniel Berrange
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Desktop 544946 None None None Never

  None (edit)
Description Adam Huffman 2008-08-09 07:43:22 EDT
Description of problem:
When I try to activate the KVM/QEMU device on localhost in order to create a new VM, the virt-manager window hangs.  Here is the relevant log output:

[Sat, 09 Aug 2008 12:31:26 virt-manager 4549] INFO (virt-manager:128) Application startup
[Sat, 09 Aug 2008 12:31:27 virt-manager 4550] DEBUG (engine:74) About to connect to uris ['qemu:///system']
[Sat, 09 Aug 2008 12:31:27 virt-manager 4550] DEBUG (connection:182) Got physical device /org/freedesktop/Hal/devices/net_00_1f_d0_20_
ad_92
[Sat, 09 Aug 2008 12:31:27 virt-manager 4550] DEBUG (connection:234) Adding net device eth1 00:1f:d0:20:ad:92 /sys/class/net/eth1 brid
ge None
[Sat, 09 Aug 2008 12:31:27 virt-manager 4550] DEBUG (connection:216) Checking for VLANs on /sys/class/net/eth1
[Sat, 09 Aug 2008 12:31:27 virt-manager 4550] DEBUG (connection:182) Got physical device /org/freedesktop/Hal/devices/net_00_1f_d0_20_
bd_83
[Sat, 09 Aug 2008 12:31:27 virt-manager 4550] DEBUG (connection:234) Adding net device eth0 00:1f:d0:20:bd:83 /sys/class/net/eth0 brid
ge None
[Sat, 09 Aug 2008 12:31:27 virt-manager 4550] DEBUG (connection:216) Checking for VLANs on /sys/class/net/eth0
[Sat, 09 Aug 2008 12:31:34 virt-manager 4550] DEBUG (connection:333) Scheduling background open thread for qemu:///system
[Sat, 09 Aug 2008 12:31:34 virt-manager 4550] DEBUG (connection:419) Background thread is running
[Sat, 09 Aug 2008 12:32:53 virt-manager 4550] DEBUG (connection:447) Background open thread complete, scheduling notify



Version-Release number of selected component (if applicable):
virt-manager-0.5.4-4.fc9.x86_64

How reproducible:

Every time

Steps to Reproduce:
1. Double-click on localhost/QEMU device
2.
3.
  
Actual results:

Window becomes unresponsive

Expected results:

Localhost/QEMU device is activated

Additional info:
Comment 1 Daniel Berrange 2008-08-11 12:25:56 EDT
This bug is yet another bug in pygobject threading - the stack trace at this point shows both threads waiting on locks

Thread 2 (Thread 0x416ee950 (LWP 5566)):
#0  0x0000000000981b34 in __lll_lock_wait () from /lib64/libpthread.so.0
#1  0x000000000097d1c0 in _L_lock_102 () from /lib64/libpthread.so.0
#2  0x000000000097cace in __pthread_mutex_lock (mutex=0x1724f30) at pthread_mutex_lock.c:86
#3  0x00007f90dd38fc7f in gdk_threads_impl_lock () at gdk.c:391
#4  0x00007f90dd38fc16 in IA__gdk_threads_enter () at gdk.c:378
#5  0x00007f90ddeb9c3a in _wrap_gdk_threads_enter (self=<value optimized out>) at ./gdk.override:133
#6  0x00000000006bf1f8 in call_function () at Python/ceval.c:3548
#7  PyEval_EvalFrameEx (f=0x2426430, throwflag=<value optimized out>) at Python/ceval.c:2267
#8  0x00000000006c0765 in PyEval_EvalCodeEx (co=0x1f56dc8, globals=<value optimized out>, locals=<value optimized out>, args=0x2039c68, argcount=1, kws=0x24223e0, 
    kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2831
#9  0x000000000065c9d7 in function_call (func=0x1fa85f0, arg=0x2039c50, kw=0x239f530) at Objects/funcobject.c:517
#10 0x000000000063e173 in PyObject_Call (func=0x1724f30, arg=0x80, kw=0x985020) at Objects/abstract.c:1860
#11 0x00000000006bdb4c in ext_do_call () at Python/ceval.c:3844
#12 PyEval_EvalFrameEx (f=0x2426260, throwflag=<value optimized out>) at Python/ceval.c:2307
#13 0x00000000006bf7bb in fast_function () at Python/ceval.c:3650
#14 call_function () at Python/ceval.c:3585
#15 PyEval_EvalFrameEx (f=0x2426030, throwflag=<value optimized out>) at Python/ceval.c:2267
#16 0x00000000006c0765 in PyEval_EvalCodeEx (co=0x16516c0, globals=<value optimized out>, locals=<value optimized out>, args=0x20397e8, argcount=1, kws=0x0, kwcount=0, 
    defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2831
#17 0x000000000065ca42 in function_call (func=0x165c320, arg=0x20397d0, kw=0x0) at Objects/funcobject.c:517
#18 0x000000000063e173 in PyObject_Call (func=0x1724f30, arg=0x80, kw=0x985020) at Objects/abstract.c:1860
#19 0x00000000006453b0 in instancemethod_call (func=0x165c320, arg=0x20397d0, kw=0x0) at Objects/classobject.c:2497
#20 0x000000000063e173 in PyObject_Call (func=0x1724f30, arg=0x80, kw=0x985020) at Objects/abstract.c:1860
#21 0x00000000006b8fc1 in PyEval_CallObjectWithKeywords (func=0x2047190, arg=0x7f90e7c91050, kw=0x0) at Python/ceval.c:3433
#22 0x00000000006e9ecd in t_bootstrap (boot_raw=0x24232a0) at Modules/threadmodule.c:424
#23 0x000000000097b40a in start_thread (arg=<value optimized out>) at pthread_create.c:297
#24 0x00007f90e7dbcb2d in clone () from /lib64/libc.so.6

Thread 1 (Thread 0x7f90e7cd16f0 (LWP 5561)):
#0  0x0000000000981321 in sem_wait () from /lib64/libpthread.so.0
#1  0x00000000006e5ac8 in PyThread_acquire_lock (lock=0x15176e0, waitflag=1) at Python/thread_pthread.h:349
#2  0x00000000006c0a04 in PyEval_RestoreThread (tstate=0x15112e0) at Python/ceval.c:312
#3  0x0000000005b81560 in libvirt_virStoragePoolGetXMLDesc () from /usr/lib64/python2.5/site-packages/libvirtmod.so
#4  0x00000000006bed5d in call_function () at Python/ceval.c:3564
#5  PyEval_EvalFrameEx (f=0x2427e00, throwflag=<value optimized out>) at Python/ceval.c:2267
#6  0x00000000006bf7bb in fast_function () at Python/ceval.c:3650
#7  call_function () at Python/ceval.c:3585
#8  PyEval_EvalFrameEx (f=0x24290f0, throwflag=<value optimized out>) at Python/ceval.c:2267
#9  0x00000000006bf7bb in fast_function () at Python/ceval.c:3650
#10 call_function () at Python/ceval.c:3585
#11 PyEval_EvalFrameEx (f=0x2427ac0, throwflag=<value optimized out>) at Python/ceval.c:2267
#12 0x00000000006c0765 in PyEval_EvalCodeEx (co=0x1f89120, globals=<value optimized out>, locals=<value optimized out>, args=0x2015ea0, argcount=6, kws=0x0, kwcount=0, 
    defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2831
#13 0x000000000065ca42 in function_call (func=0x1fa5668, arg=0x2015e88, kw=0x0) at Objects/funcobject.c:517
#14 0x000000000063e173 in PyObject_Call (func=0x15176e0, arg=0x80, kw=0x0) at Objects/abstract.c:1860
#15 0x00000000006453b0 in instancemethod_call (func=0x1fa5668, arg=0x2015e88, kw=0x0) at Objects/classobject.c:2497
#16 0x000000000063e173 in PyObject_Call (func=0x15176e0, arg=0x80, kw=0x0) at Objects/abstract.c:1860
#17 0x00000000006890ee in slot_tp_init (self=<value optimized out>, args=0x2034710, kwds=0x0) at Objects/typeobject.c:4862
#18 0x0000000000687b2e in type_call (type=<value optimized out>, args=0x2034710, kwds=0x0) at Objects/typeobject.c:436
#19 0x000000000063e173 in PyObject_Call (func=0x15176e0, arg=0x80, kw=0x0) at Objects/abstract.c:1860
#20 0x00000000006bc831 in do_call (na=0) at Python/ceval.c:3775
#21 call_function () at Python/ceval.c:3587
#22 PyEval_EvalFrameEx (f=0x2428ad0, throwflag=<value optimized out>) at Python/ceval.c:2267
#23 0x00000000006bf7bb in fast_function () at Python/ceval.c:3650
#24 call_function () at Python/ceval.c:3585
#25 PyEval_EvalFrameEx (f=0x22ff020, throwflag=<value optimized out>) at Python/ceval.c:2267
#26 0x00000000006c0765 in PyEval_EvalCodeEx (co=0x1f5ca80, globals=<value optimized out>, locals=<value optimized out>, args=0x22ff1a8, argcount=1, kws=0x230a848, 
    kwcount=0, defs=0x1fa4928, defcount=1, closure=0x0) at Python/ceval.c:2831
#27 0x00000000006bf13c in fast_function () at Python/ceval.c:3660
#28 call_function () at Python/ceval.c:3585
#29 PyEval_EvalFrameEx (f=0x230a6b0, throwflag=<value optimized out>) at Python/ceval.c:2267
#30 0x00000000006bf7bb in fast_function () at Python/ceval.c:3650
#31 call_function () at Python/ceval.c:3585
#32 PyEval_EvalFrameEx (f=0x230a410, throwflag=<value optimized out>) at Python/ceval.c:2267
#33 0x00000000006c0765 in PyEval_EvalCodeEx (co=0x1ac04e0, globals=<value optimized out>, locals=<value optimized out>, args=0x2039ba8, argcount=1, kws=0x0, kwcount=0, 
    defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2831
#34 0x000000000065ca42 in function_call (func=0x203e320, arg=0x2039b90, kw=0x0) at Objects/funcobject.c:517


It appears to stem from the fix for bug 457502


The problem is that the dummy function added in the bug's patch simply calls straight through to pyglib_enable_threads()

/* Only for backwards compatibility */
int
pygobject_enable_threads(void)
{
    if (!pyglib_enable_threads())
      return -1;

    return 0;
}

The pygobject.h and pygobject-private.h files though have macros that are still keyed off  the boolean variable 'threads_eanable' in the 'struct _PyGObject_Functions':


#define pyg_begin_allow_threads                 \
    G_STMT_START {                              \
        PyThreadState *_save = NULL;            \
        if (_PyGObject_API->threads_enabled)    \
            _save = PyEval_SaveThread();
#define pyg_end_allow_threads                   \
        if (_PyGObject_API->threads_enabled)    \
            PyEval_RestoreThread(_save);        \
    } G_STMT_END

So, even though glib/gobject threading has been enabled by calling pyglib_enable_threads(), the begin/end_allow_threads functions are not saving/restoring the python interpreter thread state.
Comment 2 Daniel Berrange 2008-08-11 12:27:22 EDT
Created attachment 313979 [details]
Set threads_enable flag

This patch augments the patch from bug 457502 to track the thread enabled state flag correctly in gobject. With this applied virt-manager is now able to connect to libvirt without hanging
Comment 3 Matthew Barnes 2008-08-12 16:33:48 EDT
Dan, can you reopen [1] with this patch so we can get it upstream?

Meanwhile I'll put it in Rawhide to give it some testing.

[1] http://bugzilla.gnome.org/show_bug.cgi?id=544946
Comment 4 Matthew Barnes 2008-08-12 16:56:35 EDT
Patch applied to pygobject2-2.15.2-3.fc10.

Setting status to MODIFIED until we get some feedback from upstream.
Comment 5 Daniel Berrange 2008-08-20 16:27:50 EDT
FYI, re comment #3, GNOME BZ doesn't allow me to re-open the bug.
Comment 6 Daniel Berrange 2008-08-21 04:14:40 EDT
*** Bug 459668 has been marked as a duplicate of this bug. ***
Comment 7 Jesse Keating 2008-10-03 19:53:54 EDT
Since this is "fixed" for Fedora, I'm going to move this off the blocker list, but leave it open so that it's tracked with the upstream.
Comment 8 Bug Zapper 2008-11-25 21:43:01 EST
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 9 Bug Zapper 2009-11-18 03:15:27 EST
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 10 Cole Robinson 2009-11-18 08:43:50 EST
Pretty sure this is fixed upstream and in all fedora versions.

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