[Python-Dev] Debugging opportunity :-)

[Phillip J. Eby]

At 06:26 PM 4/14/2006 -0400, Phillip J. Eby wrote:
>If you replace the fun_tests in test_generators with this, and remove all
>the other tests (e.g. pep_tests, tut_tests, etc.) you can still get it to
>crash.  The code above is much shorter, but has the disadvantage that I
>don't really know what it's supposed to do, other than cause a crash.  :)
>
>Interestingly, this code does *not* crash the interpreter on its own, only
>when run as a doctest (with or without regrtest).  I still haven't figured
>out what the actual problem is, but at least this cuts out all the merge()
>and times() crud in the case this was derived from, reducing it to a pure
>zen essence of non-meaning.  :)

I believe this is now the irreducible minimum code necessary to produce the 
crash:

fun_tests = """
 >>> def cycle(g):
...     yield 1
...     yield 1

 >>> def root():
...     for i in c:
...         yield i

 >>> r = root()
 >>> c = cycle(r)
 >>> c.next()
1
 >>> r.next()
1
"""

I have not been able to think of any way to further simplify this, that 
doesn't make the crash go away.  For example, if I replace the "for" loop 
inside of "root()" with  iter() and next() operations (either with or 
without a "while" loop), the crash does NOT occur.  I don't know if that's 
a red herring, or if it means the crash is inherently about there being a 
"for" loop on the stack.

I also know that the object 'r' has to be created before 'c' -- in previous 
iterations I found that just creating a cycle between two generators isn't 
enough; the one that has the paused "for" loop has to be created before the 
thing it's looping over.  I'm guessing that this means the order they're 
listed in the GC tracking lists makes a difference.