PyThread_acquire_lock freezes at pthread_cond_wait although lock not occupied

[Gernot Hillier]

Hi!

I'm now debugging a very nasty bug in a multithreadded program embedding 
Python for several days.

After quite some work I found the following:

One of the threads occasionally locks at 
PyThread_acquire_lock/pthread_cond_wait when trying to get the 
interpreter_lock or the import_lock. This thread will block there forever.

But other threads may get the same lock w/o any problem at all as it seems. 
And when I look on it in gdb it looks even more astonishing:

(gdb) bt
#0  0x4026cea9 in sigsuspend () from /lib/libc.so.6
#1  0x4003bd48 in __pthread_wait_for_restart_signal () from
    /lib/libpthread.so.0
#2  0x4003814b in pthread_cond_wait () from /lib/libpthread.so.0
#3  0x080fc44a in PyThread_acquire_lock (lock=0x81ac940, waitflag=1)
    at Python/thread_pthread.h:374
#4  0x080d3187 in PyEval_RestoreThread (tstate=0x815a358) at
    Python/ceval.c:342
#5  0x0806ac04 in capisuite_disconnect (args=0x8208bdc) at
    capisuitemodule.cpp:422
#6  0x080ab897 in PyCFunction_Call (func=0x8172fa0, arg=0x8208bdc,
    kw=0x4035bc90) at Objects/methodobject.c:90
#7  0x080d0290 in eval_frame (f=0x81e42dc) at Python/ceval.c:2004
#8  0x080d0c9c in PyEval_EvalCodeEx (co=0x826c318, globals=0xfffffffc,
    locals=0x0, args=0x81fbda4, argcount=5, kws=0x81fbdb8, kwcount=0,
    defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2585
#9  0x080d1c4d in fast_function (func=0xfffffffc, pp_stack=0xfffffffc, n=-4,
    na=5, nk=136297892) at Python/ceval.c:3161
#10 0x080d01e7 in eval_frame (f=0x81fbbec) at Python/ceval.c:2024
#11 0x080d0c9c in PyEval_EvalCodeEx (co=0x82ae2a8, globals=0xfffffffc,
    locals=0x0,args=0x81f77b8, argcount=1, kws=0x0, kwcount=0, defs=0x0,
    defcount=0, closure=0x0) at Python/ceval.c:2585
#12 0x08115f84 in function_call (func=0x8265f0c, arg=0x81f77ac, kw=0x0)
    at Objects/funcobject.c:374
#13 0x080936ae in PyObject_Call (func=0x8, arg=0x81f77ac, kw=0x0) at
    Objects/abstract.c:1684
#14 0x080d1a49 in PyEval_CallObjectWithKeywords (func=0x8265f0c,
    arg=0x81f77ac, kw=0x0) at Python/ceval.c:3049
#15 0x08093685 in PyObject_CallObject (o=0x8265f0c, a=0x81f77ac) at
    Objects/abstract.c:1675
#16 0x08066386 in PythonScript::run() (this=0x8174ee0) at
    pythonscript.cpp:80
#17 0x0806822e in IdleScript::run() (this=0x8174ee0) at idlescript.cpp:59
#18 0x40090ee1 in ost::ThreadImpl::ThreadExecHandler(ost::Thread*) ()
    from /usr/lib/libccgnu2-0.99.so.0
#19 0x4009025c in ccxx_exec_handler.1 () from /usr/lib/libccgnu2-0.99.so.0
#20 0x400391b0 in pthread_start_thread () from /lib/libpthread.so.0

Ok, it tries to get the global lock but:

(gdb) print *((pthread_lock*) interpreter_lock)
$7 = {locked = 0 '\0', lock_released = {__c_lock = {__status = 0, 
__spinlock = 0}, __c_waiting = 0x0}, mut = {__m_reserved = 0, __m_count = 0,
__m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}}

So the lock is indeed not locked!! I don't understand this at all.

The same phenomenom I saw once when trying to get the import_lock.

pthread_cond_wait () was blocked but import_lock_level was 0 and 
import_lock_thread was -1.

Anybody seen anything like this?

It occurs on GNU/Linux using pthreads from glibc 2.2.5. I'm using Python 
2.2.1 but can't see that 2.2.2 will improve this somehow...

This is very important for me as the program will get my diploma thesis and 
if I couldn't get this problem solved in the next week, I'll get in real 
trouble. :-((

So please, please if any of you has some idea which could be helpful, please 
tell me!! TIA!!!

-- 
Ciao,

Gernot