[PyKDE] pyqt/mysqld thread deadlock

[Kaleb Pederson]

On Wednesday 01 January 2003 12:50 pm, you wrote:
> Phil Thompson <phil at river-bank.demon.co.uk> writes:
> > You could try instrumenting lock_import(), or replace the mysqldb calls
> > with code that still does the imports but nothing else.
>
> Alternatively, you could also ask your debugger for a stack trace for
> all threads.
>
> Regards,
> Martin

Hmm.... switching through the various threads yields:

// although I don't display the entire traceback, this thread never acquires 
the lock.

(gdb) thread 1
[Switching to thread 1 (Thread 16384 (LWP 4220))]#0  0x4024b1be in select () 
from /lib/libc.so.6
(gdb) bt
#0  0x4024b1be in select () from /lib/libc.so.6
#1  0x40b76670 in __JCR_LIST__ () from /usr/qt/3-debug//lib/libqt-mt.so.3
#2  0x4053ed39 in QEventLoop::enterLoop() (this=0x8295368) at 
kernel/qeventloop.cpp:191
#3  0x4053ec52 in QEventLoop::exec() (this=0x8295368) at 
kernel/qeventloop.cpp:138
#4  0x40524b41 in QApplication::exec() (this=0x81c83b0) at 
kernel/qapplication.cpp:2471
#5  0x417eb27b in sipDo_QApplication_exec_loop(_object*, _object*) () from 
/usr/local/lib/python2.2/site-packages/libqtcmodule.so
#6  0x080f3ec6 in PyCFunction_Call (func=0x8801cd8, arg=0x8134124, kw=0x0) at 
Objects/methodobject.c:79
#7  0x0808ae96 in eval_frame (f=0x814d1ac) at Python/ceval.c:2014
#8  0x0808d204 in PyEval_EvalCodeEx (co=0x81462e8, globals=0x81743dc, 
locals=0x81743dc, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, 
defcount=0,
    closure=0x0) at Python/ceval.c:2595
#9  0x080828c0 in PyEval_EvalCode (co=0x81462e8, globals=0x81743dc, 
locals=0x81743dc) at Python/ceval.c:481
#10 0x080a644a in PyImport_ExecCodeModuleEx (name=0xbfffee80 
"gem.src.gui.gui", co=0x81462e8, pathname=0xbfffe540 
"/home/kibab/JDC/gem/src/gui/gui.pyc")
    at Python/import.c:505
#11 0x080a6c12 in load_source_module (name=0xbfffee80 "gem.src.gui.gui", 
pathname=0xbfffe540 "/home/kibab/JDC/gem/src/gui/gui.pyc", fp=0x8189f38)
    at Python/import.c:787
#12 0x080a76be in load_module (name=0xbfffee80 "gem.src.gui.gui", 
fp=0x8189f38, buf=0xbfffe9d0 "/home/kibab/JDC/gem/src/gui/gui.py", type=1)
    at Python/import.c:1371
#13 0x080a8d60 in import_submodule (mod=0x818a224, subname=0xbfffee8c "gui", 
fullname=0xbfffee80 "gem.src.gui.gui") at Python/import.c:1910
#14 0x080a8525 in load_next (mod=0x818a224, altmod=0x818a224, 
p_name=0xbffff2a0, buf=0xbfffee80 "gem.src.gui.gui", p_buflen=0xbfffee7c) at 
Python/import.c:1766
#15 0x080a7eee in import_module_ex (name=0x0, globals=0x8145154, 
locals=0x8145154, fromlist=0x8114484) at Python/import.c:1624
#16 0x080a81d2 in PyImport_ImportModuleEx (name=0x818a924 "gem.src.gui.gui", 
globals=0x8145154, locals=0x8145154, fromlist=0x8114484) at 
Python/import.c:1658
#17 0x080f617b in builtin___import__ (self=0x0, args=0x813d8e4) at 
Python/bltinmodule.c:40
<snip>

// Here we have the second (manager) thread
(gdb) thread 2
[Switching to thread 2 (Thread 32769 (LWP 4225))]#0  0x4024988b in poll () 
from /lib/libc.so.6
(gdb) bt
#0  0x4024988b in poll () from /lib/libc.so.6
#1  0x40030d6e in __pthread_manager () from /lib/libpthread.so.0
#2  0x40030fba in __pthread_manager_event () from /lib/libpthread.so.0

// the third thread ... this one calls lock_import() and then apparently gets 
suspended?

(gdb) thread 3
[Switching to thread 3 (Thread 16386 (LWP 4226))]#0  0x4019fd49 in sigsuspend 
() from /lib/libc.so.6
(gdb) bt
#0  0x4019fd49 in sigsuspend () from /lib/libc.so.6
#1  0x40033858 in __pthread_wait_for_restart_signal () from 
/lib/libpthread.so.0
#2  0x400300eb in pthread_cond_wait () from /lib/libpthread.so.0
#3  0x080b5c0e in PyThread_acquire_lock (lock=0x813d418, waitflag=1) at 
Python/thread_pthread.h:374
#4  0x080a5874 in lock_import () at Python/import.c:166
#5  0x080a81b2 in PyImport_ImportModuleEx (name=0x8182fc4 "types", 
globals=0x880079c, locals=0x8114484, fromlist=0x87fcc1c) at 
Python/import.c:1657
#6  0x080f617b in builtin___import__ (self=0x0, args=0x813ab0c) at 
Python/bltinmodule.c:40
<snip>

>From my limited knowledge of the Python interpreter, it looks like the lock 
only gets acquired once in the third thread.  In which case, there would be 
no reason for it to block.  But, the first thread also had some relevant 
import calls, so I'm not sure.  Where do I look now?

--Kaleb