Bug 631730

Summary: Deadlock when used from threaded program
Product: [Fedora] Fedora Reporter: Daniel BerrangĂ© <berrange>
Component: pygobject2Assignee: Colin Walters <walters>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 14CC: walters
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-08-16 21:20:43 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Release python interpreter lock when calling into C functions none

Description Daniel Berrangé 2010-09-08 09:37:43 UTC
Created attachment 445940 [details]
Release python interpreter lock when calling into C functions

Description of problem:
I have a threaded python app using PyGObject with some  GObject Introspection bindings. One thread is feeding data to another thread via a queue. More often than not, it deadlock the whole process. When this occurs I see one thread trying to obtain the python interpreter lock, while another thread is sitting in one of my app's C functions. The second thread should have released the python interpreter lock before calling into my apps' C function, but it has not.

Thread 3 (Thread 0x7f935e877710 (LWP 32193)):
#0  0x000000360500d6a0 in sem_wait () from /lib64/libpthread.so.0
#1  0x00007f9367421c38 in PyThread_acquire_lock () from /usr/lib64/libpython2.6.so.1.0
#2  0x00007f93673fb614 in PyEval_RestoreThread () from /usr/lib64/libpython2.6.so.1.0
#3  0x00007f93673834b2 in PyFile_WriteString () from /usr/lib64/libpython2.6.so.1.0
#4  0x00007f93673f622d in PyEval_EvalFrameEx () from /usr/lib64/libpython2.6.so.1.0
#5  0x00007f93673fb4e9 in PyEval_EvalCodeEx () from /usr/lib64/libpython2.6.so.1.0
#6  0x00007f9367389f70 in ?? () from /usr/lib64/libpython2.6.so.1.0
#7  0x00007f936735fdb3 in PyObject_Call () from /usr/lib64/libpython2.6.so.1.0
#8  0x00007f9367374cff in ?? () from /usr/lib64/libpython2.6.so.1.0
#9  0x00007f936735fdb3 in PyObject_Call () from /usr/lib64/libpython2.6.so.1.0
#10 0x00007f93673f3ba3 in PyEval_CallObjectWithKeywords () from /usr/lib64/libpython2.6.so.1.0
#11 0x00007f935f03d717 in _pygi_closure_handle (cif=<value optimized out>, result=0x7f935e876d60, args=<value optimized out>, data=<value optimized out>)
    at pygi-closure.c:301
#12 0x000000360e4057c9 in ffi_closure_unix64_inner () from /usr/lib64/libffi.so.5
#13 0x000000360e405fc4 in ffi_closure_unix64 () from /usr/lib64/libffi.so.5
#14 0x00007f936813650b in gvirsh_command_pipe_thread (opaque=0x7fff02953ef0) at libvirt-shell-command-pipe.c:238
#15 0x0000003604465de4 in g_thread_create_proxy (data=0x21a13b0) at gthread.c:1897
#16 0x0000003605007761 in start_thread () from /lib64/libpthread.so.0
#17 0x00000036048e14ed in clone () from /lib64/libc.so.6

Thread 2 (Thread 0x7f935de76710 (LWP 32194)):
#0  0x000000360500b3bc in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1  0x00007f936813440c in gvirsh_pipe_input_recv (input=<value optimized out>, err=<value optimized out>) at libvirt-shell-pipe.c:390
#2  0x000000360e405e5c in ffi_call_unix64 () from /usr/lib64/libffi.so.5
#3  0x000000360e405be4 in ffi_call () from /usr/lib64/libffi.so.5
#4  0x00000032e8a0a1ff in g_function_info_invoke (info=<value optimized out>, in_args=0x7f9358005770, n_in_args=1, out_args=0x0, n_out_args=0, return_value=
    0x7f935de75300, error=0x7f935de75310) at gifunctioninfo.c:417
#5  0x00007f935f038b31 in _invoke_function (self=0x7f935ee12350, py_args=0x7f935ee12650) at pygi-invoke.c:537
#6  _wrap_g_function_info_invoke (self=0x7f935ee12350, py_args=0x7f935ee12650) at pygi-invoke.c:904
#7  0x00007f93673f972d in PyEval_EvalFrameEx () from /usr/lib64/libpython2.6.so.1.0
#8  0x00007f93673fb4e9 in PyEval_EvalCodeEx () from /usr/lib64/libpython2.6.so.1.0
#9  0x00007f93673f9897 in PyEval_EvalFrameEx () from /usr/lib64/libpython2.6.so.1.0
#10 0x00007f93673fb4e9 in PyEval_EvalCodeEx () from /usr/lib64/libpython2.6.so.1.0
#11 0x00007f9367389f70 in ?? () from /usr/lib64/libpython2.6.so.1.0
#12 0x00007f936735fdb3 in PyObject_Call () from /usr/lib64/libpython2.6.so.1.0
#13 0x00007f9367374cff in ?? () from /usr/lib64/libpython2.6.so.1.0

Looking at the code, the problem is simply that  the _invoke_function() method in pygobject is missing calls to

    pyg_begin_allow_threads;
    pyg_end_allow_threads;

This is still missing in latest upstream GIT too

Version-Release number of selected component (if applicable):
pygobject2-2.21.5-3.fc14

How reproducible:
Hard, requires a threaded app, with many calls out to the C layer.

Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Fedora End Of Life 2012-08-16 21:20:46 UTC
This message is a notice that Fedora 14 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 14. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained.  At this time, all open bugs with a Fedora 'version'
of '14' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this 
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen 
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we were unable to fix it before Fedora 14 reached 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, you are encouraged to click on 
"Clone This Bug" (top right of this page) and open it against that 
version of Fedora.

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