[Zope-dev] Re: segfaults in cPersistence under 2.6

[Tim Peters]

[Anthony Baxter]
> *sigh*
>
> So I tried a fresh checkout on a different box, no crash.
> Completely nuked old checkout (which was a new checkout
> last night), checked out again, rebuilt, no crash.
>
> Beats me. I'm going to blame the electrician who took out
> power to our floor this morning, because it's that or
> cosmic rays.

I hate these.  Causes for stuff "like this" in the past included:

+ "make clean" not cleaning everything it should have cleaned.

+ Compiling not recompiling everything it should have recompiled.

+ Wild load or store in Zope or Python's C code.  These *can* be
  extremely touchy, appearing to go away for weeks at a time,
  and never occurring on some peoples' machines.

I've only seen one instance of that last one triggered by Zope, which turned
out to be a bug in Python (fixed long ago) specific to the intersection of
Python's new-style classes and Zope's ExtensionClass.

Jeremy and I saw cases of ring corruption while putting together the
experimental ZODB 3.3, but they were 100% reproducible on all platforms, and
turned out to have clear causes (some of the C objects we backported from
ZODB4 were getting ghostified by the ZODB4 code without removing themselves
from the ZODB3 ring).  So "ring corruption" rang a bell for me, but not one
that makes any sense in your context.

Keep your eyes open, Anthony!  If it happens again, I want to know.