Wow. I'm having _so_ much fun with 2.6. I'm now seeing a reproducible
segfault on startup.
Program received signal SIGSEGV, Segmentation fault.
0xfe4517c8 in accessed (self=0xedbe58) at ZODB/cPersistence.c:160
160 self->ring.next->prev = self->ring.prev;
(gdb) p self
$1 = (cPersistent
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)
{
On Friday 25 July 2003 08:30, Anthony Baxter wrote:
> More information: I don't see the failure with a fresh Data.fs. The
> Data.fs in question is my 2.5 one.
Do you have any custom persistent extension classes stored in that Data.fs
that might not have been updated to the 2.6 persistence C API?
>>> Toby Dickenson wrote
> On Friday 25 July 2003 08:30, Anthony Baxter wrote:
> > More information: I don't see the failure with a fresh Data.fs. The
> > Data.fs in question is my 2.5 one.
>
> Do you have any custom persistent extension classes stored in that Data.fs
> that might not have been
Anthony Baxter wrote:
Is it possible that there's a C code product that's not been updated? How would I
figure out what it might be?
Are you running the DynPersist extension from ZPatterns? That would
need to be recompiled.
Also note that "python setup.py build" doesn't reliably rebuild the
BTr
