[Zope-dev] Threading deadlock in ZServer 1.1b1?

[Skip Montanaro]

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