On Mon, 22 Mar 2004, Dieter Maurer wrote:
Zope got a SIGSEGV because the C runtime stack overflew (application bug).
One of the Zope threads died as a result of the SIGSEGV. The others entered an unhealthy state: process "1" became their parent, they could only be attached by "gdb" as user "root", they held Zope's ports open, they could only be killed by "kill -9".
Thank you for the information! Can you tell a bit more about what was wrong? Can this be triggered by bugs in Python scripts, ZPT or DTML? Or was it a bug in C extension code? I think I'm going to have a hard time tracking this down, so any clues could help. I'm considering updating Zope to 2.7.0 (from 2.6.4) with Python 2.3.3 in the hope that it might help. Is this futile?
Shane shed some light on the situation:
Python blocks signals in threads other than the main thread. Thus, only the main thread receives signals (other than SIGSEGV)
This is documented behaviour but arguably wrong for SIGSEGV (and some further signals).
Should this issue be considered a bug in either Python or Zope? It doesn't seem like very robust behavior. If it only happens when debugging then that's passable, but for me it happens on an almost-production setup during normal use. Of course if it's just a bad C extension (I don't have many, just PIL, egenix-mx-base and egenix-mx-experimental) then there's not that much Zope or Python can do about it. -Osma -- *** Osma Suominen *** ozone@iki.fi *** http://www.iki.fi/ozone/ ***