> 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/mail
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 post
Antoine writes:
> Mark Hammond 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
Mark Hammond 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 prob
While looking at 2.6 for Windows, I've found a recursion related crash in
test_cpickle on 64bit builds. Specifically, the 'cPickleDeepRecursive' is
causing a stack overflow, and the debugger tells me the actual recursion
depth was 629 at the crash.
The reason the 64bit build doesn't see more cras
