[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(),
#ifdef USE_STACKCHECK
if (PyOS_CheckStack()) {
PyErr_SetString(PyExc_MemoryError, "stack overflow");
return -1;
}
#endif
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;
} __except (EXCEPTION_EXECUTE_HANDLER) {
/* 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
error.
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
raised.
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
Linux.
Remains unclear what to do about it; the idea that all errors raised by dict
lookup comparisons are ignorable is sure a tempting target.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4