GNOME Bugzilla – Bug 149741
pygtk deadlocks when using TreeSelection.select_iter from a new thread with a handler attached to the "changed" signal
Last modified: 2005-08-22 12:49:47 UTC
The summary says it all. Selecting something from the main thread works. Selecting something from another thread works, but only if I haven't attached something to the selections "changed" signal. If I have attached something, it gets called when selecting from the main thread, but not when selecting from the other thread, and the application locks. Unfortunately I cannot currently get stack backtraces from gdb for multithreaded apps (probably because of an issue with nptl and symbols stripped from glibc). Running the program through valgrind (with "valgrind --tool=helgrind --trace-children=yes --num-callers=10 python gtktest.py") reported: sched status: Thread 1: status = WaitMX, associated_mx = 0x1DFAAC38, associated_cv = 0x0 ==8365== at 0x1D4BD0F7: pthread_mutex_lock (vg_libpthread.c:1324) ==8365== by 0x1DDE0A4C: (within /usr/lib/libgdk-x11-2.0.so.0.400.4) ==8365== by 0x1DE0B508: (within /usr/lib/libgdk-x11-2.0.so.0.400.4) ==8365== by 0x490D195A: g_main_context_check (in /usr/lib/libglib-2.0.so.0.400.4) ==8365== by 0x490D1ECF: (within /usr/lib/libglib-2.0.so.0.400.4) ==8365== by 0x490D2542: g_main_loop_run (in /usr/lib/libglib-2.0.so.0.400.4) ==8365== by 0x1DC23AA2: gtk_main (in /usr/lib/libgtk-x11-2.0.so.0.400.4) ==8365== by 0x1DAAFE72: _wrap_gtk_main (in /usr/lib/python2.3/site-packages/gtk-2.0/gtk/_gtk.so) ==8365== by 0x49007866: (within /usr/lib/libpython2.3.so.1.0) ==8365== by 0x4900571C: (within /usr/lib/libpython2.3.so.1.0) Thread 2: status = WaitCV, associated_mx = 0x1D9D8218, associated_cv = 0x1D9D8230 ==8365== at 0x1D4BD426: pthread_cond_wait (vg_libpthread.c:1452) ==8365== by 0x1D4C1535: sem_wait (vg_libpthread.c:2764) ==8365== by 0x490280F5: PyThread_acquire_lock (in /usr/lib/libpython2.3.so.1.0) ==8365== by 0x4900318C: PyEval_RestoreThread (in /usr/lib/libpython2.3.so.1.0) ==8365== by 0x49021D93: PyGILState_Ensure (in /usr/lib/libpython2.3.so.1.0) ==8365== by 0x1DA0A457: pyg_closure_marshal (in /usr/lib/python2.3/site-packages/gtk-2.0/gobject.so) ==8365== by 0x49080048: g_closure_invoke (in /usr/lib/libgobject-2.0.so.0.400.4) ==8365== by 0x49092EBB: (within /usr/lib/libgobject-2.0.so.0.400.4) ==8365== by 0x49091EB3: g_signal_emit_valist (in /usr/lib/libgobject-2.0.so.0.400.4) ==8365== by 0x490921B3: g_signal_emit (in /usr/lib/libgobject-2.0.so.0.400.4) ==8365== ==8365== Warning: pthread scheduler exited due to deadlock but this might not be reliable (there were also some warnings about unimplemented threading features in valgrind that might cause the app to misbehave). All this was with python 2.3.3 and pygtk 2.3.96 with the patch http://www.gnome.org/~johan/pygboxed-threading.diff applied. I will attach my test program in a moment.
Created attachment 30373 [details] testcase This should select "foo" in the list, then select "bar" after a one second delay, and print "log called!" to the console each time the selection changed. It hangs before "bar" is selected, and only prints "log called!" once. If I comment out the line 'selection.connect("changed", log)' it works.
I'm quite sure this is a dup of bug 149845
Off-topic: your gdb threading problem is probably what is described here: http://www.skynet.ie/~caolan/TechTexts/OpenOfficeHacking.html
I agree this is probably a dup. I had other threading difficulties since upgrading pygtk, this was one I could reproduce with a reasonably small testcase. I'll close it (if I can) and reopen if it still happens after bug 149845 is fixed. Offtopic: you're probably right about the gdb problem, but I didn't feel like rebuilding my glibc unstripped because I didn't know if that had any other negative consequences. Thanks for the pointer. *** This bug has been marked as a duplicate of 149845 ***