[Psycopg] Re: [Zope] Zope crashing

[Dieter Maurer]

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
_______________________________________________
Psycopg mailing list
Psycopg@lists.initd.org
http://lists.initd.org/mailman/listinfo/psycopg