[Python-Dev] another dict crasher

Tim Peters tim@digicool.com
Tue, 5 Jun 2001 17:01:23 -0400

[Tim's dict-crasher dies w/ a stack overflow, but with a KeyError when
 he sticks a print inside __eq__]

OK, I understand this now, at least on Windows.  In PyObject_Print(),

	if (PyOS_CheckStack()) {
		PyErr_SetString(PyExc_MemoryError, "stack overflow");
		return -1;

On Windows, PyOs_CheckStack() is

	__try {
		/* _alloca throws a stack overflow exception if there's
		   not enough space left on the stack */
		_alloca(PYOS_STACK_MARGIN * sizeof(void*));
		return 0;
		/* just ignore all errors */
	return 1;

The _alloca dies, so the __except falls thru and PyOs_CheckStack returns 1.
PyObject_Print sets the "stack overflow" error and returns -1.  This winds
its way thru the rich comparison attempt, until lookdict() sees it and says,

    Hmm.  I can't compare this thing without raising error.  So
    this can't be the key I'm looking for.  First I'll clear the
    Hmm.  Can't find it anywhere else in the dict either.
    Hmm.  There were no errors pending at the time I got called,
    so I'll leave things that way and return "not found".

At that point about 15,000 levels of recursion unwind, and KeyError gets

I don't believe PyOS_CheckStack() is implemented on Unixoid systems (just
Windows and Macs), so some other accident must account for the KeyError on

Remains unclear what to do about it; the idea that all errors raised by dict
lookup comparisons are ignorable is sure a tempting target.