[Python-Dev] Re: Another test_compiler mystery

[Grzegorz Makarewicz]

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