I thought a recent operating system upgrade (FreeBSD 5.4 to 6.1) fixed my problems with Zope. Unfortunately, once I re-compiled Python et al (to remove dependencies on the old libraries), my problems with Zope deadlocking recurred. I tried to use a combination of tools to try to discover the root cause of this problem, but nothing seems to work. What am I missing, and what else can I try? This system is: Nokia IP440 (Pentium II-333MHz, 256 MB RAM) FreeBSD 6.1-RELEASE-p1 Python 2.3.5 Zope 2.8.6 Plone 2.1.2 Trace and event logs: I set up the trace log to save all messages, and the last few lines of the access, event, and trace logs are: Z2.log: 127.0.0.1 - Anonymous [15/Jun/2006:22:52:54 -0400] "GET /VirtualHostBase/http/web.irtnog.org:80/irtnog/VirtualHostRoot/irtnog/he lpcenter_icon.gif HTTP/1.1" 200 1322 "http://web.irtnog.org/howtos-orig/freebsd-pf-pppoe" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)" event.log: 2006-06-15T22:40:28 INFO Plone Debug Error exceptions.AttributeError on getBeginAndEndTimes while rendering portlet here/portlet_simpleblog/macros/portletBlogFull_local trace.log: B 221198124 2006-06-15T22:52:54 GET /VirtualHostBase/http/web.irtnog.org:80/irtnog/VirtualHostRoot/Members/x enophon/photos/washdc-jan-2006/photoalbum_view?b_start:int=20 I 221198124 2006-06-15T22:52:54 0 DeadlockDebugger + threadframe: Once the Zope process deadlocks, it ceases to respond on port 8080 (the configured listener port). Thus it is not possible to obtain a thread dump from Zope using this package. Lsof: I checked the list of open files on the Zope process but didn't see anything out of the ordinary (attached as "zope-lsof.txt") Strace/Truss/Ktrace: I traced the process using ktrace, dumped it with "kdump -H" to get thread IDs, and got the following information: 7505 100075 python2.3 PSIG SIGSEGV SIG_DFL 7505 100075 python2.3 PSIG SIGSEGV SIG_DFL 7505 100075 python2.3 PSIG SIGSEGV SIG_DFL 7505 100075 python2.3 PSIG SIGSEGV SIG_DFL 7505 100075 python2.3 PSIG SIGSEGV SIG_DFL 7505 100075 python2.3 PSIG SIGSEGV SIG_DFL 7505 100075 python2.3 PSIG SIGSEGV SIG_DFL 7505 100075 python2.3 PSIG SIGSEGV SIG_DFL 7505 100075 python2.3 PSIG SIGSEGV SIG_DFL 7505 100075 python2.3 PSIG SIGSEGV SIG_DFL I traced the process using truss and got the following information: SIGNAL 11 (SIGSEGV) SIGNAL 11 (SIGSEGV) SIGNAL 11 (SIGSEGV) SIGNAL 11 (SIGSEGV) SIGNAL 11 (SIGSEGV) SIGNAL 11 (SIGSEGV) Strace showed the same information: --- SIGSEGV (Segmentation fault: 11) --- --- SIGSEGV (Segmentation fault: 11) --- --- SIGSEGV (Segmentation fault: 11) --- --- SIGSEGV (Segmentation fault: 11) --- --- SIGSEGV (Segmentation fault: 11) --- --- SIGSEGV (Segmentation fault: 11) --- --- SIGSEGV (Segmentation fault: 11) --- --- SIGSEGV (Segmentation fault: 11) --- GDB + attach + info threads (https://engineering.purdue.edu/ECN/Resources/KnowledgeBase/Docs/2006051 8104722): The faulting thread seems to be in the middle of pthread_mutexattr_init. (gdb) info threads * 7 LWP 100075 0x2820e5c2 in pthread_mutexattr_init () from /usr/lib/libpthread.so.2 6 Thread 0x8111000 (sleeping) 0x2820df0f in pthread_mutexattr_init () from /usr/lib/libpthread.so.2 5 Thread 0xa318a00 (LWP 100062) 0x2821546b in pthread_testcancel () from /usr/lib/libpthread.so.2 4 Thread 0x991ac00 (runnable) 0x00000000 in ?? () 3 Thread 0x9062400 (runnable) 0x0cea3a2c in ?? () 2 Thread 0x9a37a00 (sleeping) 0x2820df0f in pthread_mutexattr_init () from /usr/lib/libpthread.so.2 1 Thread 0x9a35800 (sleeping) 0x2820df0f in pthread_mutexattr_init () from /usr/lib/libpthread.so.2 None of the threads are in the sigsuspend, poll, select, or kill state, although it's possible that the sleeping state is equivalent to sigsuspend. At a whim, I tried stepping into the process, but this didn't do anything other than show the SEGV on the console. (gdb) call PyRun_SimpleString("import string,sys,os,ZServer; sys.stdout=open('/tmp/urls','w',0); print string.join(map(lambda a:str(getattr(a,'env',{}).get('PATH_INFO','')), sys.modules['asyncore'].socket_map.values()), '\\n')") Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x9062400 (LWP 100075)] 0x0cea3a2c in ?? () The program being debugged was signaled while in a function called from GDB. And: (gdb) call PyRun_SimpleString("import sys, traceback;sys.stderr=open('/tmp/tb','w',0); traceback.print_stack()") [Switching to Thread 0x9062400 (LWP 100114)] Cannot set lwp 100114 registers: Invalid argument Cannot set lwp 100114 registers: Invalid argument -- jsoffron: I'm generally pretty high on national defense... Mr. Bad Example: Careful...it's a gateway policy. Before you know it, you'll be mainlining the hard stuff like trade agreements. jsoffron: Too late...I've been freebasing Nafta all day... Sweet, sweet NAFTA. - As seen on Slashdot