[Zope-dev] segfaults in cPersistence under 2.6

[Anthony Baxter]

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.