[Zope-dev] Segfault in Acquisition in Zope 2
Sylvain Viollon
sylvain at infrae.com
Mon Aug 15 06:27:33 EDT 2011
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
More information about the Zope-Dev
mailing list