Has anyone encountered deadlocks in the threading code in ZServer 1.1b1? I do not use threads in my code and I can see no way to disable the thread code in ZServer. Attaching to the hung process produces the following nearly useless gdb traceback: #0 0x400a4bb4 in __syscall_sigsuspend () #1 0x400c675c in __DTOR_END__ () #2 0x40013ef3 in pthread_cond_wait () at condvar.c:148 #3 0x8061f82 in PyThread_acquire_lock () #4 0x80794fd in lock_PyThread_acquire_lock () #5 0x8053fad in call_builtin () #6 0x8053ec4 in PyEval_CallObjectWithKeywords () #7 0x8052f3d in eval_code2 () #8 0x8052dfd in eval_code2 () #9 0x80542d8 in call_function () #10 0x8053eba in PyEval_CallObjectWithKeywords () #11 0x8066f42 in PyInstance_New () #12 0x8053fc3 in call_builtin () #13 0x8053ec4 in PyEval_CallObjectWithKeywords () #14 0x807961a in t_bootstrap () #15 0x40014c56 in pthread_start_thread (arg=0xbf9ffd28) at manager.c:165 I tried using the trick Barry Warsaw posted recently about getting a Python traceback with the following gdb command: call PyRun_SimpleString("import sys, traceback; \ sys.stderr=open('/tmp/tb','w',0); traceback.print_stack()") but that invariably fails to produce anything. I will try building Python with -g so I can at least muck about in the C call stack, but I'm hoping someone has encountered this problem and has some suggestions. I saw nothing useful in the bugs reported for ZServer. (My wild-ass guess is that some client is behaving badly - perhaps the user pushes the stop button at the wrong time or the client crashes - which causes some infrequently executed exit path to be taken which doesn't release whatever lock has been acquired, but that's mere speculation at this point.) <stopped-in-scotia> Skip Montanaro | http://www.mojam.com/ skip@mojam.com | http://www.musi-cal.com/~skip/ 518-372-5583