Then, this is a case where you need debugging on C level, e.g. with "GDB".
You need a Python version with debug symbols (those installations that come with the OS distribution usually lack them, you need to build your Python yourself -- and with it your Zope).
Then you attach the Zope process (the top level process, in case that threads show as processes as well) when the problem occurs and analyse its threads -- especially the one that is running when you attached.
If the problem occurs in Python (which is unlikely), then I can provide you with GDB command definitions to analyse the Python call chain (the Python traceback) from the C-level backtrace.
Dear Paul, Dear Dieter, thank you for your help. I followed the instructions from http://www.zopelabs.com/cookbook/1073504990. I've built my Python myself. After I installed "GDB", I ran the following commans: ------------------------------------------------------------------------- gdb python2.4 (gdb) info threads (gdb) attach 6613 (gdb) thread 1 (gdb) call PyRun_SimpleString("import sys, traceback; sys.stderr=open('/tmp/tb','w',0); traceback.print_stack()") ------------------------------------------------------------------------- Unfortunately, there is no '/tmp/tb' file written. Below, you'll see the results after each command: ------------------------------------------------------------------------- gdb python2.4 GNU gdb 6.6 Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "x86_64-unknown-linux-gnu"... Using host libthread_db library "/lib64/libthread_db.so.1". (gdb) attach 6613 Attaching to program: /usr/local/bin/python2.4, process 6613 Reading symbols from /lib64/libpthread.so.0...done. [Thread debugging using libthread_db enabled] [New Thread 47050976353024 (LWP 6613)] [New Thread 1107310912 (LWP 6617)] [New Thread 1098918208 (LWP 6616)] [New Thread 1090525504 (LWP 6615)] [New Thread 1082132800 (LWP 6614)] Loaded symbols for /lib64/libpthread.so.0 Reading symbols from /lib64/libdl.so.2...done. # ...a lot of Loaded / Reading here... (gdb) info threads 5 Thread 1082132800 (LWP 6614) 0x00002acae820e3fd in sem_wait () from /lib64/libpthread.so.0 4 Thread 1090525504 (LWP 6615) 0x00002acae820e3fd in sem_wait () from /lib64/libpthread.so.0 3 Thread 1098918208 (LWP 6616) 0x00002acae820e3fd in sem_wait () from /lib64/libpthread.so.0 2 Thread 1107310912 (LWP 6617) 0x00002acae820e3fd in sem_wait () from /lib64/libpthread.so.0 1 Thread 47050976353024 (LWP 6613) 0x00002acae8a3e202 in ?? () from /lib64/libc.so.6 # (The thread "6613" is the process Id listed if I check "top". (gdb) thread 1 [Switching to thread 1 (Thread 47050976353024 (LWP 6613))]#0 0x00002acae8a3e202 in ?? () from /lib64/libc.so.6 (gdb) call PyRun_SimpleString("import sys, traceback; sys.stderr=open('/tmp/tb','w',0); traceback.print_stack()") Program received signal SIGSEGV, Segmentation fault. 0x000000000048fb9d in PyImport_AddModule (name=0x4d5ae9 "__main__") at Python/import.c:320 320 PyInterpreterState *interp = PyThreadState_GET()->interp; The program being debugged was signaled while in a function called from GDB. GDB remains in the frame where the signal was received. To change this behavior use "set unwindonsignal on" ------------------------------------------------------------------------- After I attached the pid "6613", Zope does not answers anymore until I quit "GDB". Is this the normal behavior? Any idea, why no '/tmp/tb' logfile is created? Thank you very much in advance, Nico