A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from http://mail.python.org/pipermail/python-dev/2004-August/047721.html below:

[Python-Dev] Re: Another test_compiler mystery

[Python-Dev] Re: Another test_compiler mysteryTim Peters tim.peters at gmail.com
Thu Aug 12 17:23:23 CEST 2004
[Michael Hudson <mwh at python.net]
> Has the failure mode of alloca() changed?

No, and the Windows stack-check code works fine.  I showed results
before from boosting the amount of padding the Windows stack-check
code checks for, and it if checks for 20x more  (which is ridiculously
large) padding than it checks for now, it reliably generates Python
stack-overflow MemoryErrors.

Indeed, the KeyError exceptions were traced specifically to this:  a
stack-overflow MemoryError, due to the Windows stack-check code,
getting wiped out by lookdict (whose caller took lookdict's NULL
return as meaning the key wasn't present in the dict -- although it
actually was).

> I take it you're building with VC++ 7.1?

Right.

> What happens for a VC++ 6 build?

Raymond reported on that earlier.  Appeared to be the same as I saw in
a release build.  He didn't report on a debug build.  He's running
WinME, so a "hard" failure may look quite different for him.

> 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?

Right, no difference.

> It still smells like a tool change to me.

Not to me.  Although it does smell.
More information about the Python-Dev mailing list

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