Mayers, Philip J writes:
I'm still seeing periodic/sporadic crashes of my Zope installation, and it's getting *REALLY* annoying :o)
I sometimes get a core file (if I'm lucky) whose backtrace normally reads:
Program terminated with signal 11, Segmentation fault. <snip> #0 0x401364fe in __select () from /lib/libc.so.6 (gdb) bt #0 0x401364fe in __select () from /lib/libc.so.6 #1 0x4031708c in __DTOR_END__ () from /usr/lib/libpq.so.2 #2 0x4030ecad in PQgetResult () from /usr/lib/libpq.so.2 #3 0x4030ee1c in PQexec () from /usr/lib/libpq.so.2 #4 0x402f9acb in curs_switch_autocommit () from .... I would not believe this backtrace:
It is quite unlikely that the program gets a Segmentation fault in "select". I see only two possiblities. The first parameter, "n" (number of relevant file descriptors), is too high and your OS does not check for this (unlikely) or one of the "in/out" parameters "readfds", "writefds" and "exceptfds" is not properly allocated. However, Zope is a multi-threaded process. I have spent hours and days with misleading backtraces of the type above. I finally noticed that often the debugger was lying. It showed the backtrace of the main thread while the Segmentation Fault had been caused in a completely different thread. Furthermore, your program modules seem to be compile without debugging symbols. In this case, you do not see the correct funktions called but only the nearest global symbol above the current location. This may be very confusing. When you really want to track the problem down, compile everything with debugging information. Do not trust the association of signals with threads (often signals are assiciated with the main thread, not the one that caused them). Dieter