[Thomas Wouters] > ... > One remaining issue with refleakhunting on my machine is that test_tcl can't > stand being run twice. Even without -R, this makes Python hang while waiting > for a mutex in the second run through test_tcl: > > ...trunk $ ./python -E -tt Lib/test/regrtest test_tcl test_tcl > > Attaching gdb to the hung process shows this unenlightening trace: > #0 0x00002b7d6629514b in __lll_mutex_lock_wait () from /lib/libpthread.so.0 > #1 0x00002b7d6639a280 in completed.4801 () from /lib/libpthread.so.0 > #2 0x0000000000000004 in ?? () > #3 0x00002b7d66291dca in pthread_mutex_lock () from /lib/libpthread.so.0 > #4 0x0000000000000000 in ?? () > > The process has one other thread, which is stuck here: > #0 0x00002b7d667f14d6 in __select_nocancel () from /lib/libc.so.6 > #1 0x00002b7d67512d8c in Tcl_WaitForEvent () from /usr/lib/libtcl8.4.so.0 > #2 0x00002b7d66290b1c in start_thread () from /lib/libpthread.so.0 > #3 0x00002b7d667f8962 in clone () from /lib/libc.so.6 > #4 0x0000000000000000 in ?? () > > It smells like test_tcl or Tkinter is doing something wrong with regards to > threads. I can reproduce this on a few machines, but all of them run newish > linux kernels with newish glibc's and newish tcl/tk. At least in kernel/libc > land, various thread related things changed of late. I don't have access to > other machines with tcl/tk right now, but I wonder if anyone can reproduce > this in different situations.
FYI, there's no problem running test_tcl with -R on WinXP Pro SP2 from current trunk: C:\Code\python\PCbuild>python_d -E -tt ../lib/test/regrtest.py -R:: test_tcl test_tcl beginning 9 repetitions 123456789 ......... 1 test OK. [27306 refs] That's using Tcl/Tk 8.4.12 (I don't know what newish means in Tcl-land these days). _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com