[Python-Dev] new failing test -- test_compiler

[Tim Peters]

[Jeremy Hylton]
> I added a test for the compiler package, because I realized it would
> easily fall out of date if the language changed (say, decorators were
> added) and the compiler package wasn't updated.  I added a test with a
> resource, so it would only fail if you run regrtest.py -u all.  I
> think that's a little lame, but better than letting us get into beta
> without getting the compiler package fixed.
>
> At any rate, the test become somewhat more interesting than I expected
> because it fails in an unexpected way:
>
> Fatal Python error: deletion of interned string failed
> Aborted (core dumped)
> 
> My best guess is that this is a stack overflow.

I assume you ran this on Linux.  If so, and it is a stack overflow,
then it's very peculiar that it dies in much the same way on Windows:

"""
$ regrtest.py -uall test_compiler
test_compiler
Fatal Python error: deletion of interned string failed

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
"""

Anyone know who the support team for Python might be?

> In particular, gdb shows that the failure is 388 stack levels deep.

I've seen Zope gdb stack traces a lot deeper than that, so it's not
necessarily indicative of a blown stack.

> The compiler package has very deep function calls, because it uses
> recursion to traverse abstract syntax trees.  (I know, I know, we should just
> rewrite the compiler to use iterator instead of recursion <wink>.)  Inside one of
> those deeply nested calls, it triggers GC which attempts to free a
> deeply nested tree that is now garbage.  I think that's where it blows
> up.  If anyone has suggestions for debugging, I'm all ears.

Same thing on Windows.  This is the string it's trying to delete:

"abcdfeghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789_"

If that's the string it's trying to delete for you too, my suggestion
is that you find out why <wink>.  Seriously, it smells more like "a
real bug" to me.

	op->ob_refcnt = 3;
	if (PyDict_DelItem(interned, op) != 0)
		Py_FatalError(
			"deletion of interned string failed");

sets the refcount to 3 first, and the refcount is 4 when the program
dies.  That means PyDict_DelItem took its

	if (ep->me_value == NULL) {
		PyErr_SetObject(PyExc_KeyError, key);
		return -1;
	}

path.  It's all consistent on Windows with a non-stack-overflowing
genuine error.