Re: [Python-Dev] Python 2.6 on AMD64 recusion crash
Hi Mark, 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. I believe it's the wrong diagnosis :) If you look at http://bugs.python.org/issue3373 and the small script I posted, there are paths where the actual recursion level is still 1000. Furthermore: 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. [...] The 32bit windows versions of Python do exactly this and nominate 2MB, which the 64bit builds inherited. 2MB divided by 629 is more than 3KB. It means each cPickle recursion level consumes more than 3KB of stack. It sounds awful enough to be considered a bug in cPickle, IMO. 2MB is plenty of stack space. Regards Antoine. ___ 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
Re: [Python-Dev] Python 2.6 on AMD64 recusion crash
I believe it's the wrong diagnosis :) As I mentioned in the bug, I believe you are correct :) Thanks! 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
Re: [Python-Dev] Python 2.6 on AMD64 recusion crash
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. Please open a bug for the problem. 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. Regards Antoine. ___ 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
Re: [Python-Dev] Python 2.6 on AMD64 recusion crash
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
