You are right. This is not a new problem, though. In our working branch at CCP, we have this particular test disabled for this reason. It could be an idea to add the python recursion guard calls even to safe-pickle.
Btw, I'm not sure why Christian deemed pickling to be enough of a special case to warrant special pickling code with stack-spilling. Perhaps pickling tasklet regularly caused such deep recursions that this was necessary. If that is the case, then we shoulnd't impose artificial recursion limits... I think we ought to leave this as an open issue in the "stackless defect tracking database in the sky" :) K > -----Original Message----- > From: [email protected] [mailto:stackless- > [email protected]] On Behalf Of Jeff Senn > Sent: 1. júlí 2010 18:08 > To: The Stackless Python Mailing List > Subject: Re: [Stackless] stackess for 2.7 > > > On Jul 1, 2010, at 12:08 PM, Jeff Senn wrote: > > > Speaking of 64bit... are you compiling a 64bit version? I am having > some trouble... > > In particular test_cpickle crashes (segfault) in test_issue2702 > (__main__.cPickleDeepRecursive) > > Update on this: > > Note the test (an attempt to pickle a deeply nested unrealistic object) > is designed to fail due to excessive recursion. > > It appears that in 64-bit mode this test only survives down to a > recursion limit of about 273 (note: < 1000) before things go horribly > wrong -- I'm guessing that the greater stack requirements of 64 bit > simply cause a problem (compared to the 32-bit version) and the > simplest solution is just to reduce the recursion limit for that > build... (It's hard to determine the "final cause" of the crash as the > debugger is messed up when I get there... probably crunching the stack? > dunno...) > > However (caveat: as I said the pickling part of stackless is not my > favorite...) it seems like the stackless bit that avoids the call to > Py_EnterRecursiveCall in cPickle.c, and instead uses slp_safe_pickling, > is sort of asking for trouble in this case. > > In this test (in non-stackless python), the excessive recursion of the > cPickle module itself (calling 'save') is detected by the > Py_EnterRecursiveCall check. In stackless (I think) this test is > bypassed (due to the unwind of pickling) and the recursion count grows > significantly more slowly (and only incidentally due to a deeper call > to Py_CallObject.) > > I'm not sure if there is a simple and satisfying fix... > > > > > > _______________________________________________ > Stackless mailing list > [email protected] > http://www.stackless.com/mailman/listinfo/stackless _______________________________________________ Stackless mailing list [email protected] http://www.stackless.com/mailman/listinfo/stackless
