Ok - sounds fine. More generally my 64 bit build also crashes on many of the stackless tests - so I suspect a general problem as well (possibly a platform specific one -- as they are generally, slightly post stack swap).
I don't really rely on a 64 bit build at the moment for my work (since I have other dependencies that keep me at 32) -- is the amd64 build supposed to work? On Jul 3, 2010, at 5:18 AM, Kristján Valur Jónsson wrote: > 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 > _______________________________________________ Stackless mailing list [email protected] http://www.stackless.com/mailman/listinfo/stackless
