I have a problem in my application that Zope segfault. I spend lot of time 
trying to narrowing the issue.

   To identify the problem quickly, I compiled Python in debug mode (to get all 
the assert and so on). As well I have
   my own WSGI publisher. I could not trigger the problem with ZServer 
(probably there are locks that prevent the problem
   to appear with ZServer, but I could not find them). As well, I forced a 
garbage collection at the end of each Zope
   requests. The problem occurs in garbage collection, and is identified by an 
assertion with Python in debug mode:

   Assertion failed: (gc->gc.gc_refs != 0), function update_refs, file 
Modules/gcmodule.c, line 311.

   (The comment in Python above that assert explains the bug that is happening).

   With this Python, I can reproduce using my application the problem just by 
displaying any ZMI screen (it
   assert/segfault right away if the browser cache is empty).

   The issue only happens in ZMI, and is triggered by the ZMI resources, stored 
using OFS.misc_.
   Resources in misc_ are set as attributes on a class (so they are module 
level variable, shared among
   all application threads), that is itself set as an attribute on the root 

   If, after the configuration of Zope, I monkey patch the misc_ and p_ 
attributes on the root Application, the ZMI
   obviously looks ugly but doesn't segfault, and works in a stable fashion.

   If I restrict my application to one thread only (without the monkey patch 
above) the ZMI works and doesn't
   segfault. 2 or more threads trigger the problem almost right away.

   I changed my content type icons in my application to be exported to the user 
using browser resources
   (provided by the Five product). That works and is stable. But I cannot 
change all the Zope built-in resources
   to do the same, instead of using that misc_ hack (which will be nicer I 
think anyway).

   If I let the application segfault (without the assert), I have a null 
pointer issues in an ImplicitAcquisitionWrapper
   that already have its content freed, and looks like it want to free it again.

   This looks like a race condition bug when accessing those resources exported 
using misc_. I tried, unsuccessfully
   up until now to write a small script that could reproduced the problem 
without all my application stack.

   I have this problem with:

   - Python 2.6 and Zope 2.12

   - Python 2.7 and Zope 2.13

   (All the latest ones).

   This have been observed on 64 bits computers (Mac OS X, FreeBSD and Linux). 
I don't know about 32 bits

   Do you have any clues for me ?



Sylvain Viollon -- Infrae
t +31 10 243 7051 -- http://infrae.com
Hoevestraat 10 3033GC Rotterdam -- The Netherlands

Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope )

Reply via email to