[Python-Dev] Crash in new "trashcan" mechanism.

[Christian Tismer]

Greg Stein wrote:
> 
> On Thu, 13 Apr 2000, Mark Hammond wrote:
> >...
> > I see these possible solutions:
> >
> > * The trash mechanism is changed to keep a list of (address,
> > deallocator) pairs.  This is a "cleaner" solution, as the list is
> > not considered holding PyObjects as such, just blocks of memory to
> > be freed with a custom allocator.  Thus, we never end up in a
> > position where a Python objects are resurrected - we just defer the
> > actual memory deallocation, rather than attempting a delayed object
> > destruction.  This may not be as trivial to implement as to describe
> > :-)

This one sounds quite hard to implement.

> > * Debug builds disable the trash mechanism.  Not desired as the
> > basic behaviour of the interpreter will change, making bug tracking
> > with debug builds difficult!  If we went this way, I would (try to
> > :-) insist that the Windows debug builds dropped Py_DEBUG, as I
> > really want to avoid the scenario that switching to a debug build
> > changes the behaviour to this extent.

I vote for this one at the moment.

> > * Perform further hacks, so that Py_ForgetReference() gracefully
> > handles NULL linked-list elements etc.
> >
> > Any thoughts?
> 
> Option 4: lose the trashcan mechanism. I don't think the free-threading
> issue was ever resolved.

Option 5: Forget about free threading, change trashcan in a way
that it doesn't change the order of destruction, doesn't need
memory at all, and therefore does not change anything if it is
disabled in debug mode.

cheers - chris

-- 
Christian Tismer             :^)   <mailto:tismer@appliedbiometrics.com>
Applied Biometrics GmbH      :     Have a break! Take a ride on Python's
Kaunstr. 26                  :    *Starship* http://starship.python.net
14163 Berlin                 :     PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
     where do you want to jump today?   http://www.stackless.com