[Python-Dev] Re: Another test_compiler mystery

Michael Hudson mwh at python.net
Thu Aug 12 12:33:48 CEST 2004


Tim Peters <tim.peters at gmail.com> writes:

> Here's some puzzling evidence (WinXP Pro SP1).  The test driver, for
> convenience:
>
> """
> import compiler, sys
>
> f = open('../Lib/test/test_parser.py')
> guts = f.read()
> f.close()
>
> def ouch(n):
>     if n == 0:
>         return compiler.compile(guts, "<string>", "exec")
>     else:
>         return ouch(n-1)
>
> for n in range(0, 50):
>     try:
>         ouch(n)
>         msg = 'ok'
>     except KeyboardInterrupt:
>         raise
>     except Exception, msg:
>         msg = str(sys.exc_info()[0]) + ' ' + str(msg)
>     print n, msg
> """
>
> The loop starts at 0 this time, and I'm only looking at a debug-build Python.
>
> The stack size for an .exe can be specified to 4-byte granularity. 
> Here's the largest stack size at which that produces no output at all:
>
> C:\Code\python\PCbuild>editbin /stack:1310720 python_d.exe
> Microsoft (R) COFF Binary File Editor Version 6.00.8447
> Copyright (C) Microsoft Corp 1992-1998. All rights reserved.
>
> C:\Code\python\PCbuild>python_d temp.py
>
> C:\Code\python\PCbuild>echo %ERRORLEVEL%
> 128
>
>
> Add 4 measly bytes, and it's a world of difference:
>
> C:\Code\python\PCbuild>editbin /stack:1310724 python_d.exe
> Microsoft (R) COFF Binary File Editor Version 6.00.8447
> Copyright (C) Microsoft Corp 1992-1998. All rights reserved.
>
>
>
> C:\Code\python\PCbuild>python_d temp.py
> 0 ok
> 1 ok
> ...
> 41 ok
> 42 ok
>
> C:\Code\python\PCbuild>echo %ERRORLEVEL%
> 128
>
> 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.

Has the failure mode of alloca() changed?  I take it you're building
with VC++ 7.1?  What happens for a VC++ 6 build?

Hmm, a moment with msdn suggests that there's been no significant
changes here, although the documentation is for _alloca(), and Python
calls alloca().  That can't make any difference, can it?

It still smells like a tool change to me.

Cheers,
mwh

-- 
58. Fools ignore complexity. Pragmatists suffer it. Some can avoid
    it. Geniuses remove it.
  -- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html


More information about the Python-Dev mailing list