[Zope-dev] 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 )
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 <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: TALES idea: tuple unpacking
On Thu, Jul 24, 2003 at 11:00:09AM +0200, Jean Jordaan wrote:
> Perhaps it's worthwhile for this thread to have a look at
> http://www.eby-sarna.com/pipermail/transwarp/2003-July/000606.html
> http://www.eby-sarna.com/pipermail/transwarp/2003-July/000607.html
> and following to see what Phillip Eby is cooking up.
>
> The templates he proposes have only two or three attributes,
> keeping logic rigorously out of the template.
Very interesting idea. Here's an excerpt:
"""
I think that ZPT still embed code in a web page, and that there's a better
alternative. If you've seen PSO (pso.sf.net), Twisted's Woven, or even JSP
taglibs (though that's a bit of a stretch), you'll have a better idea of
what PWT (peak.web.templates) looks like. Here's an example, straight from
the test suite:
Title Goes Here
'view' attributes identify the object factory used to create the tag,
'model' attributes are a path to the data to be used, and 'pattern'
attributes identify parameters that are supplied to the nearest containing
'view', rather like a METAL macro slot (except that views are written in
Python, rather than being templates, although I intend to make it possible
to use a template as a view, too). Views are looked up in a property
namespace so you can configure access to arbitrary view components that
your app (or anybody else) supplies
"""
I don't totally grok it (an object factory creates a tag?
does he mean the contents of the tag? and since they're factories written
in python shouldn't they be called something other than 'views'? like
maybe 'factory'??). But, odd terminology aside, it's compellingly simple.
I guess that the 'view' and the 'model' only have to agree on an
interface ('pattern' names).
--
Paul Winkler
http://www.slinkp.com
Look! Up in the sky! It's DEPUTY SHERIFF OF JUSTICE!
(random hero from isometric.spaceninja.com)
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: TALES idea: tuple unpacking
I only use 2 because it's there :-) Thinking more about it, it occurs to me that python expressions in TALES provide a huge hole in the separation of presentation from logic. Perhaps it's worthwhile for this thread to have a look at http://www.eby-sarna.com/pipermail/transwarp/2003-July/000606.html http://www.eby-sarna.com/pipermail/transwarp/2003-July/000607.html and following to see what Phillip Eby is cooking up. The templates he proposes have only two or three attributes, keeping logic rigorously out of the template. -- Jean Jordaan http://www.upfrontsystems.co.za ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
