Mailing List Archive: Zope: Coders

SEGFAULT using ComputedAttribute

Index | Next | Previous | View Threaded

deo at plonesolutions

Jan 18, 2005, 3:12 PM

Post #1 of 7 (1847 views)
Permalink

SEGFAULT using ComputedAttribute

Hello folks,

Introduction
============

I'm working to improve the reliability of ExternalStorage[1], an
Archetypes addon who provides a filesystem storage that can be
used (in theory) for any field.

The problem
===========

Some AT pieces rely in the presence of an attribute containing
the data it wants to access. This attribute should behave exactly
as calling the field accessor method (sorry for the AT specific
terminology). Normally, this kind of thing is a trivial task done
by ComputedAttribute, to mimics the results of an original method
call. When I try to use the ComputedAttribute trick, I make Zope
SEGFAULT... :-(

Details
=======

Considering a schema containing a field 'test', I need to create
an attribute 'test' on each instance which use the schema.

This new property should have the same value as when calling
'instance.getTest()', which is done by 'field.get()' as we are
playing with the 'test' field.

Segfaulting
===========

I'm setting the new property at field initialization time, as
we have all needed elements: self (the storage), instance (the
current object instance) and field (our 'test' field):

def initializeField(self, instance, field):
name = field.getName()
if not hasattr(aq_base(instance), name):
# This should create a 'test' attribute on the
# current instance, with the same value of a
# field.get method call
setattr(instance, name, ComputedAttribute(field.get, 1))

In fact, it seems to (almost) work as expected, because all the
'functional' (testFuncional.py, where I use 'self.publish()') tests
pass.

The SEGFAULTs happens when accessing the parent instance, or when
doing a copy/paste operation (reproducible at testCopy.py).

Probably I'm abusing of ComputedAttribute, but I can't think in
any other solution. Any thought is highly appreciated! :-)

Reproducing the error
=====================

You can reproduce the error with a current checkout from Archetypes
release-1_3-branch[2] and from ExternalStorage trunk[1], changing
initializeField method as above and running the tests.

I can provide any additional info on request.

Thanks for your attention.

[1]http://cvs.sf.net/viewcvs.py/collective/ExternalStorage
[2]http://svn.plone.org/archetypes/Archetypes/branches/release-1_3-branch

--
_____________________________________________________________________

Dorneles Treméa · Developer · Plone Solutions · Brazil

Consulting · Training · Development · http://www.plonesolutions.com
_____________________________________________________________________

Plone Foundation · http://plone.org/foundation · Protecting Plone

_______________________________________________
Zope-Coders mailing list
Zope-Coders [at] zope
http://mail.zope.org/mailman/listinfo/zope-coders

abo at minkirri

Jan 18, 2005, 5:34 PM

Post #2 of 7 (1761 views)
Permalink

Re: SEGFAULT using ComputedAttribute [In reply to]

On Tue, 2005-01-18 at 21:12 -0200, Dorneles Treméa wrote:
> Hello folks,
[...]
> call. When I try to use the ComputedAttribute trick, I make Zope
> SEGFAULT... :-(

I'm not familiar with your particular application, but I thought I'd
offer some observations about our experiences with ComputedAttribute
that may help.

ComputedAttribute is buried in C extension land, but it calls back to
Python land when it invokes the method. If _any_ exception is raised by
the Python method, it is not handled in C land and you get a segfault.
You can find these kinds of errors by putting a catch-all exception
handler in your computed attribute method that prints out diagnostics.

It is very easy to find yourself in recursive-land, recursing until you
run out of memory and get a segfault. Make sure there is no way that
your computed attribute method tries to access its own attribute, or
another computed attribute that depends on this attribute.

When you pass in the extra '1' to indicate "use aquisition wrappers",
you actually end up with "self" aquistion wrapped as in self.aq_inner.
This means you get only the "containment" wrapper. There doesn't seem to
be any way to make it use the full aquisition wrappers. I think this is
a result of how it is implemented. If your method does not rely on the
object being aquisition wrapped, it is better to not specify "1".

--
Donovan Baarda <abo [at] minkirri>
http://minkirri.apana.org.au/~abo/

_______________________________________________
Zope-Coders mailing list
Zope-Coders [at] zope
http://mail.zope.org/mailman/listinfo/zope-coders

deo at plonesolutions

Jan 18, 2005, 7:51 PM

Post #3 of 7 (1774 views)
Permalink

Re: SEGFAULT using ComputedAttribute [In reply to]

Hi,

> [snipped problem explanation]
>
> The SEGFAULTs happens when accessing the parent instance, or when
> doing a copy/paste operation (reproducible at testCopy.py).

supposing that the traceback just before the SEGFAULT can help:

(Pdb) w
/usr/local/zope/cvs/ExternalStorage/tests/tests/testCopy.py(72)?()
-> framework()

/usr/local/zope/Zope/lib/python/Testing/ZopeTestCase/ztc_common.py(31)framework()
-> result = TestRunner(stream, descriptions, verbosity).run(test_suite())
/usr/lib/python2.3/unittest.py(658)run()
-> test(result)
/usr/lib/python2.3/unittest.py(389)__call__()
-> test(result)
/usr/lib/python2.3/unittest.py(389)__call__()
-> test(result)

/usr/local/zope/Zope/lib/python/Testing/ZopeTestCase/profiler.py(68)__call__()
-> self.setUp()

/usr/local/zope/Zope/lib/python/Testing/ZopeTestCase/PortalTestCase.py(52)setUp()
-> self.afterSetUp()

/usr/local/zope/cvs/ExternalStorage/tests/tests/testCopy.py(27)afterSetUp()
-> res = self.folder.manage_pasteObjects(cb)

/usr/local/zope/Zope/lib/python/OFS/CopySupport.py(173)manage_pasteObjects()
-> ob=ob._getCopy(self)

/usr/local/zope/Instance1/Products/Archetypes/Referenceable.py(322)_getCopy()
-> ob = CopySource._getCopy(self, container)
/usr/local/zope/Zope/lib/python/OFS/CopySupport.py(455)_getCopy()
-> ob=container._p_jar.importFile(f)
> /usr/local/zope/Zope/lib/python/ZODB/ExportImport.py(85)importFile()
-> t.commit(1)
(Pdb) n
SEGFAULT

Thanks in advance.

--
_____________________________________________________________________

Dorneles Treméa · Developer · Plone Solutions · Brazil

Consulting · Training · Development · http://www.plonesolutions.com
_____________________________________________________________________

Plone Foundation · http://plone.org/foundation · Protecting Plone

_______________________________________________
Zope-Coders mailing list
Zope-Coders [at] zope
http://mail.zope.org/mailman/listinfo/zope-coders

dman at dman13

Jan 19, 2005, 9:39 AM

Post #4 of 7 (1763 views)
Permalink

Re: SEGFAULT using ComputedAttribute [In reply to]

On Tue, Jan 18, 2005 at 09:12:52PM -0200, Dorneles TremÃ©a wrote:
[...]
| The problem
| ===========
|
| Some AT pieces rely in the presence of an attribute containing
| the data it wants to access. This attribute should behave exactly
| as calling the field accessor method (sorry for the AT specific
| terminology). Normally, this kind of thing is a trivial task done
| by ComputedAttribute, to mimics the results of an original method
| call. When I try to use the ComputedAttribute trick, I make Zope
| SEGFAULT... :-(
[...]

I discovered that if you try to store an instance of a class that does
not inherit from Persistent then Zope can crash when the ZODB tries to
store that object. Perhaps you are inadvertently trying to do the
same thing?

-D

--
One OS to rule them all, one OS to find them,
One OS to bring them all and in the darkness bind them,
In the Land of Redmond, where the Shadows lie.

www: http://dman13.dyndns.org/~dman/ jabber: dman [at] dman13

Attachments:

signature.asc (0.18 KB)

deo at plonesolutions

Jan 19, 2005, 10:08 AM

Post #5 of 7 (1764 views)
Permalink

Re: SEGFAULT using ComputedAttribute [In reply to]

Hi Derrick,

> I discovered that if you try to store an instance of a class that does
> not inherit from Persistent then Zope can crash when the ZODB tries to
> store that object. Perhaps you are inadvertently trying to do the
> same thing?

thanks for the info. I also already heard about it, but never got
*hit* by it! :-)

What's the recommended way to see what is 'pending' (all objects) at
current transaction and will be commited when calling t.commit()? Is
there also an easy way to check for the Persistent objects?

--
_____________________________________________________________________

Dorneles Treméa · Developer · Plone Solutions · Brazil

Consulting · Training · Development · http://www.plonesolutions.com
_____________________________________________________________________

Plone Foundation · http://plone.org/foundation · Protecting Plone

_______________________________________________
Zope-Coders mailing list
Zope-Coders [at] zope
http://mail.zope.org/mailman/listinfo/zope-coders

dman at dman13

Jan 21, 2005, 3:29 PM

Post #6 of 7 (1753 views)
Permalink

Re: SEGFAULT using ComputedAttribute [In reply to]

On Wed, Jan 19, 2005 at 04:08:38PM -0200, Dorneles TremÃ©a wrote:
| Hi Derrick,
|
| >I discovered that if you try to store an instance of a class that does
| >not inherit from Persistent then Zope can crash when the ZODB tries to
| >store that object. Perhaps you are inadvertently trying to do the
| >same thing?
|
| thanks for the info. I also already heard about it, but never got
| *hit* by it! :-)
|
| What's the recommended way to see what is 'pending' (all objects) at
| current transaction and will be commited when calling t.commit()? Is
| there also an easy way to check for the Persistent objects?

I don't know what the recommended way is. I happened to figure it out
in my case by reading a relevant note in some documentation and by
explicitly trying it. In my case I was moving some objects using
_setObject() so it was quite simple for me, once I realized that's
what caused the segfault.

-D

--
The Consultant's Curse:
When the customer has beaten upon you long enough, give him
what he asks for, instead of what he needs. This is very strong
medicine, and is normally only required once.

www: http://dman13.dyndns.org/~dman/ jabber: dman [at] dman13

Attachments:

signature.asc (0.18 KB)

chris at simplistix

Jan 24, 2005, 1:55 AM

Post #7 of 7 (1764 views)
Permalink

Re: Re: SEGFAULT using ComputedAttribute [In reply to]

Derrick Hudson wrote:

> | What's the recommended way to see what is 'pending' (all objects) at
> | current transaction and will be commited when calling t.commit()? Is
> | there also an easy way to check for the Persistent objects?
>
> I don't know what the recommended way is. I happened to figure it out
> in my case by reading a relevant note in some documentation and by
> explicitly trying it. In my case I was moving some objects using
> _setObject() so it was quite simple for me, once I realized that's
> what caused the segfault.

This sounds like something the good folk on zodb-dev [at] zope may be
able to help with...

Chris

--
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
_______________________________________________
Zope-Coders mailing list
Zope-Coders [at] zope
http://mail.zope.org/mailman/listinfo/zope-coders

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads