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.

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

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

Patch applied to pygobject2-2.15.2-3.fc10.

Setting status to MODIFIED until we get some feedback from upstream.

FYI, re comment #3, GNOME BZ doesn't allow me to re-open the bug.

*** Bug 459668 has been marked as a duplicate of this bug. ***

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.

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

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

Pretty sure this is fixed upstream and in all fedora versions.