More information: I don't see the failure with a fresh Data.fs. The Data.fs in question is my 2.5 one. I'm running the current HEAD of Zope-2_6-branch. I packed the Data.fs, the same result. I've added a simple function to 2.6's cPersistence.c: static void ringcheck(CPersistentRing *start) { CPersistentRing *s, *t; int i=0; s = start; t = start; if (!s) { return; } for (;;) { assert(s == s->next->prev); assert(s == s->prev->next); s = s->next; i++; if (s == t) { break; } } printf("ringcheck ok, %d items\n", i); } I then hooked into calling it from accessed(), ghostify() and unghostify() and I'm seeing it consistently corrupted after 103 items end up in the ring. I also turned on MUCH_RING_CHECKING in cPickleCache.c, but it failed to see anything broken. Interestingly, at the point it's detecting that the ring is busted (rather than when it trips over the breakage, later on) ##1 0xfe451914 in accessed (self=0xeddb00) at ZODB/cPersistence.c:184 ##2 0xfe452834 in Per_getattr (self=0xeddb00, oname=0x594368, name=0x59437e "bjects", getattrf=0xfe6d7cec <EC_findiattro>) at ZODB/cPersistence.c:551 ##3 0xfe4528f4 in Per_getattro (self=0xeddb00, name=0x594368) at ZODB/cPersistence.c:566 ##4 0x64bd8 in PyObject_GetAttr (v=0xeddb00, name=0x594368) at Objects/object.c:1052 Maybe it's just me, but that name="bjects" looks suspicious as hell.