Segfault in Acquisition in Zope 2

Hello,

   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 Application.

   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
   installations.

   Do you have any clues for me ?

   Regards,

   Sylvain,

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



_______________________________________________
Zope-Dev maillist  -  [email protected]
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )