This bug is only a hypothetical bug -- from source 
code inspection it appears clear that it can happen, 
and we have a Zope user who is reporting crashes that 
are consistent with this, but it isn't confirmed that 
this is indeed the cause.  Tim is attempting to 
reproduce it while I'm typing this.

The trashcan code stores NULL or other values in the 
ob_type field of an object, while that object is still 
in the GC doubly-linked list of container objects.  
When the collector is invoked, it dereferences ob_type 
(specifically, in subtract_refs, it retrieves ob_type-
>tp_traverse and calls it).  Obviously, the value 
stored in ob_type by the trashcan code causes this to 
fail.

This bug occurs in all versions of Python that have 
the GC code enabled (i.e. 2.0 and above).  In 2.1 and 
before, the code looks different than in 2.2, but the 
effect is the same: the trashcan code abuses ob_type 
of an object that's in a GC generational chain.

If we fix this, a 2.1.3 release including the fix 
should be issued, and we should hold up the final 
release of 2.2.1 to include a fix as well.

Logged In: YES 
user_id=31435

Attaching a brief program (tup.py) that provokes a crash 
quickly, at least on Windows.  The crash goes away if the 
trashcan limit is boosted above the depth of tuple nesting 
this program creates.

Logged In: YES 
user_id=35752

The fix should be simple.  Coming soon. :-)

Logged In: YES 
user_id=35752

Well, not as simple as I had hoped.  Attached is a rough
patch that fixes the bug (I think, I haven't had time to
really study the interaction between GC and the trashcan
macros).

Logged In: YES 
user_id=6380

Alas, that fixes it for tuples, but not for lists. I've
uploaded the list example as lis.py.

We also need a fix for 2.1.2 (to help the Zope user who
originally ran into this) and one for 2.2.1 -- the latter is
needed quickly if we want to make the final release.

Logged In: YES 
user_id=6380

Here's a patch for the 2.1 maintenance branch. AFAICT this
fixes the problem for lists, tuples and dicts, which is a
100% fix (the other trashcan objects, frames and tracebacks,
don't use GC).

Note: the dict test case is just like the tuple or list
testcase, but has
  t = {1: t, 2: Ouch()}
as the last line of f().

Logged In: YES 
user_id=378059

Leo in Brazil (the Zope customer experiencing the problem)
has bumped the trashcan depth limit up to 5 million, and
been stable for the entire overnight and morning production
periods.

He confirms the description and I believe he will be trying
the patch today.

Logged In: YES 
user_id=105700

Ouchh!
I will look into this and find an alternative
implementation. My current abuse of the type field
interacts with that fact that GC still needs it.
We just moved into a new house, I will not be
online often over Easter. Will sove it in the
coming week.
ciao - chris

Logged In: YES 
user_id=105700

Ouchh!
I will look into this and find an alternative
implementation. My current abuse of the type field
interacts with that fact that GC still needs it.
We just moved into a new house, I will not be
online often over Easter. Will sove it in the
coming week.
ciao - chris

Logged In: YES 
user_id=35752

I'm not sure the abuse of the ob_type pointer is the only
problem we are facing here.  I've have a patch that changes
trashcan so that it doesn't overwrite the ob_type pointer.
I can still make the interpreter crash.  I'm still trying
to understand this problem completely. :-(

Logged In: YES 
user_id=6380

Well, it *also* abuses the ob_refcnt field.

How about this wild idea (which Tim & I had simultaneously
yesterday): change the trashcan code to simply leave the
object in the GC generational list, and let the GC code
special-case objects with zero refcnt so that they are
eventually properly disposed?

Logged In: YES 
user_id=6380

Looks like there are at least two independent bugs exposed
by the lis.py example in the CVS trunk/head: on Windows,
traversing the frame object can encounter freed object
because of the way the SETLOCAL() macro first decrefs
fastlocals[i] and then assigns it a new value. I've got a
fix for this (separate, see ceval.c.diff attached). On
Linux, the traceback points to the brand new semaphore code;
haven't researched this further yet.

Logged In: YES 
user_id=6380

The new semaphore code is innocent -- it wasn't even used in
this case.

I cannot reproduce the bug with Neil's patch + my ceval.c
patch any more, so I consider this case closed.

I'll check the necessary things in to the 2.1 and 2.2
maintenance branches. Neil, can you check in your patch to
the trunk?

Logged In: YES 
user_id=6380

Closing this; fixes have been checked in.

Maybe someone (Tim?) can check in the test case? Only the
trunk seems sufficient.

Christian: no need for a new trashcan IMO.

Logged In: YES 
user_id=31435

Just noting that I added a test case to test_gc.py in the 
trunk.

Logged In: YES 
user_id=35752

I'm working on the trashcan code fix right now (use gc_prev
instead of ob_type).  I was going to check it in but an
interpreter built --without-cycle-gc and with Py_DEBUG
defined crashes.  I don't know if our recent changes broke
things of if --without-cycle-gc has been broken for a while.

Logged In: YES 
user_id=31435

Sorry, Neil, no clue -- PythonLabs likely builds every day 
in release and debug (Py_DEBUG) modes, each using all 
platform defaults, but I don't believe any of us ever 
builds in any other way.