[ZODB-Dev] RE: [Zope-Annce] ZODB 3.2.4 release candidate 1released

Dieter Maurer dieter at handshake.de
Wed Sep 15 14:13:43 EDT 2004


Chris McDonough wrote at 2004-9-15 02:29 -0400:
> ...
>I'm trying to figure out a reported error case for Transience that
>involves a problem that manifests itself in a symptom like this:
>
>>> iobtree = IOBTree()
>>> iobtree[1] = 1
>>> iobtree[2] = 2 
>>> keys = list(iobtree.keys(None, 100))
>>> for key in keys:
>>>    del iobtree[key]
>KeyError: 1

> ...
>I'm wondering if this sounds like a
>plausible series of events under Zope-2.7.2 + its version of ZODB that
>might explain it:
>
>- a reference to a soon-to-be-unreachable object is created
>  via the "pending modifications in subtransactions reused
>  from cache when txn not committed or aborted" bug.  This
>  object is referenced in a leaf node by a bucket of an
>  IOBTree and its key is also kept by the IOBTree itself in
>  its interior node structure.
>
>- the unreachable object is eventually ghosted in some thread
>
>- The IOBTree's keys() method is called.  It returns what it thinks
>  is the set of keys it has.
>
>- The set of keys is iterated over and __delitem__ is called on
>  the BTree with each key.  When it reaches the ghosted object and
>  tries to unghost it, a POSKeyError is generated.  (does it *need*
>  to unghost it?)
>
>- Whatever code implements __delitem__ on a BTree catches the
>  POSKeyError and reraises it as a KeyError

I checked the BTrees code: it does not catch "POSKeyError" (and convert it
into "KeyError"). The relevant code is in fact in the macro
"PER_USE_OR_RETURN", defined in "ZODB.cPersistence.h".

-- 
Dieter


More information about the ZODB-Dev mailing list