[Python-Dev] Re: Another test_compiler mystery (original) (raw)

Grzegorz Makarewicz mak at trisoft.com.pl
Thu Aug 12 13:08:45 CEST 2004

Tim Peters wrote:

So it still vanishes early, but gets thru the entire compiler.compile() business + 42 additional stacked Python calls! That's awfully impressive for four bytes. That suggests "the problem" isn't in detecting Python-level recursion. Under the debugger, it dies with an access violation at that point. Alas, the C-level Python call stack is no longer anywhere in evidence then. Instead it's 7 levels deep in ntdll.dll, and is "in the middle" of four consecutive Pentium PUSH instructions. That's evidence that the stack has been blown . The debugger Output window does show ntdll.dll suffering a Stack Overflow exception. It then shows a variety of Access Violations in ntdll.dll trying to read and write various locations, presumably in a failing attempt to report the stack overflow.

I have copied stack check into PyObject_Malloc and after X calls to PyEval_EvalFrame, fast_function python dies in malloc(msvcrt) and HeapAlloc (ntdll) as described by Tim.

After this patch most ocurring exception is MemoryError, but for 141, 171, 201 and 231 python raises SyntaxError - always witout traceback :(

mak

relevant part from obmalloc.c:

PyObject_Malloc(size_t nbytes) { block *bp; poolp pool; poolp next; uint size;

#ifdef USE_STACKCHECK if (PyOS_CheckStack()) { return NULL; } #endif

More information about the Python-Dev mailing list