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