[Python-Dev] new failing test -- test_compiler (original) (raw)

Tim Peters tim.peters at gmail.com
Sat Aug 7 21:53:22 CEST 2004

[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 .) 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 . 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.

More information about the Python-Dev mailing list