[Python-Dev] Re: Another test_compiler mystery (original) (raw)
Tim Peters tim.peters at gmail.com
Thu Aug 12 17:23:23 CEST 2004
- Previous message: [Python-Dev] Re: Another test_compiler mystery
- Next message: [Python-Dev] Re: Another test_compiler mystery
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[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.
- Previous message: [Python-Dev] Re: Another test_compiler mystery
- Next message: [Python-Dev] Re: Another test_compiler mystery
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]