[Zope] zope 2.6.4 lockups

Osma Suominen ozone+zope at sange.fi
Tue Mar 23 05:05:26 EST 2004


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 at iki.fi *** http://www.iki.fi/ozone/ ***



More information about the Zope mailing list