[Stackless] stackess for 2.7

[Jeff Senn]

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: stackless-bounces at stackless.com [mailto:stackless-
>> bounces at stackless.com] 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
>> Stackless at stackless.com
>> http://www.stackless.com/mailman/listinfo/stackless
> 
> 
> _______________________________________________
> Stackless mailing list
> Stackless at stackless.com
> http://www.stackless.com/mailman/listinfo/stackless
>