[Python-Dev] Re: Another test_compiler mystery
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 <wink>.
>
> 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