Antoine writes: > Mark Hammond <mhammond <at> skippinet.com.au> writes: > > > > However, test_cpickle takes a different path and doesn't see this > doubling of > > the count - therefore dieing at the depth of 629 that I can see. > > 629 is a very low number, far lower than the default recursion limit of > 1000.
Yes, exactly - that is the point. If we got to 1000 Python would have prevented us going any further. As it was, we ran out of stack space at 629. I believe that this is the only path that allows us to go past an *actual* recursion level of 1/2 the nominated maximum value due to that other regression I mentioned. > Please open a bug for the problem. http://bugs.python.org/issue3640 > > My solution to this was to simply double the stack size for the > > executables > > in 64bit builds, from 2MB to 4MB (2.1 and 4.2 for debug builds.) Is > > this an appropriate fix? > > Unless this can be set in the configure script for all affected > architectures, I'm not sure this is ok. IIUC, each platform and architecture has its own stack requirements, so therefore it is the responsibility of that platform to ensure enough stack is available for a depth of 1000. The 32bit windows versions of Python do exactly this and nominate 2MB, which the 64bit builds inherited. It seems 2MB isn't enough for 64bit Windows, and doubling it seemed like a fairly safe way to go. So while other 64bit platforms may well need adjusting if they use the same values as their 32bit versions, that is independent of what Windows 64bit builds need to do. Obviously, all IIUC <wink> Cheers, Mark _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com