segfaults in cPersistence under 2.6
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 = (cPersistentObject *) 0xedbe58 (gdb) p self->ring $2 = {prev = 0xe5d8fc, next = 0xeb7b210c} (gdb) p self->ring.prev $3 = (struct CPersistentRing_struct *) 0xe5d8fc (gdb) p self->ring.next $4 = (struct CPersistentRing_struct *) 0xeb7b210c (gdb) p self->ring.next->prev Cannot access memory at address 0xeb7b210c. #0 0xfe4517c8 in accessed (self=0xedbe58) at ZODB/cPersistence.c:160 #1 0xfe4526b4 in Per_getattr (self=0xedbe58, oname=0xbf280, name=0xbf295 "as_key", getattrf=0xfe6d7cec <EC_findiattro>) at ZODB/cPersistence.c:524 #2 0xfe452774 in Per_getattro (self=0xedbe58, name=0xbf280) at ZODB/cPersistence.c:539 #3 0x64bd8 in PyObject_GetAttr (v=0xedbe58, name=0xbf280) at Objects/object.c:1052 #4 0x21c34 in eval_code2 (co=0x8090f8, globals=0x49daac, locals=0x8, args=0xbf280, argcount=2, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:1773 #5 0x245b8 in call_eval_code2 (func=0x80ac24, arg=0xd9230c, kw=0x0) at Python/ceval.c:2979 #6 0x24108 in call_object (func=0x80ac24, arg=0xd9230c, kw=0x0) at Python/ceval.c:2818 #7 0x23f64 in PyEval_CallObjectWithKeywords (func=0x80ac24, arg=0xd9230c, kw=0x0) at Python/ceval.c:2753 #8 0xfe6d4614 in callMethodWithPossibleHook (inst=0xea55d8, meth=0x80ac24, args=0xd9230c, kw=0x0) The code in question is here: /* Do nothing unless the object is in a cache and not a ghost. */ if (self->cache && self->state >= 0) { CPersistentRing *home = &self->cache->ring_home; self->ring.prev->next = self->ring.next;
self->ring.next->prev = self->ring.prev;
self->ring.next = home; self->ring.prev = home->prev; home->prev->next = &self->ring; home->prev = &self->ring; }
So it seems that the ring's getting corrupted in some way. Any tips on tracking this down? I'm thinking of a simple function that just zips around the ring checking that it's sane in both directions... (yes, I've confirmed that all the C extensions have been rebuilt cleanly). -- Anthony Baxter <anthony@interlink.com.au> It's never too late to have a happy childhood.
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.
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 - http://www.geminidataloggers.com/people/tdickenson Want a job like mine? http://www.geminidataloggers.com/jobs for Software Engineering jobs at Gemini Data Loggers in Chichester, West Sussex, England
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 updated to the 2.6 persistence C API?
Nope. The only C-code Product that's been added to this Zope (aside from those that ship with the system) is DCOracle/ZOracleDA, and I'm pretty certain that it's not doing anything with C code persistence. Is it possible that there's a C code product that's not been updated? How would I figure out what it might be? Anthony -- Anthony Baxter <anthony@interlink.com.au> It's never too late to have a happy childhood.
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 BTrees extensions and maybe others. I often use "python setup.py build_ext -if". Shane
participants (3)
-
Anthony Baxter -
Shane Hathaway -
Toby Dickenson