Hi Anselm, right, but is that not just a matter of proper reconstruction of the linkage? I think we introduced traceback pickling as well, so we are free to choose its representation, too. And that could be a list or something, whatever gives a simple and obvious structure with no recursion that is hard to introspect.
cheers - Chris On 11.03.14 11:29, Anselm Kruis wrote: > Hi, > > just a comment about pickling frames. I noticed the odd behaviour of > f_back being None a while ago during my work on pyheapdump. This > design decision breaks pickling of trace-back objects. That could be a > reason to reconsider frame pickling. > > Cheers > Anselm > > > > Am 07.03.2014 17:50, schrieb Christian Tismer: >> Frame stacks: >> >> Yes, for some reason I did the pickling of frame stacks as a list >> that is not linked in the pickle. >> >> One reason was just for easier debugging, because the frame stack >> is just a list that has a length, there is no chance of doing something >> wrong, no recursive stuff going on, etc. >> >> There is also the consideration that the way of linking does not >> necessarily have to be by using f_back, while sitting in a pickle. >> Remember, the reference counting on f_back is a little different on >> CPython and Stackless, actually an implementation detail that does >> not belong into the pickle. >> >> Keeping the frame stack as a list was the most natural way for me to >> handle this. >> >> I believe the fact that f_back == None is also used as a marker of >> """this frame came fron unpickling""". >> >> Without a need to improve this, I would like to keep it this way. >> >> cheers - Chris >> >> >> On 06/03/14 10:01, Kristján Valur Jónsson wrote: >>> I'm not sure I understand. >>> What exactly is blocking us? >>> I fixed the unittest crash. The rest of my question was musings on >>> how frame pickling works, >>> because it seems to only pickle one frame at a time, marking its >>> parent with the special valid None >>> to indicate this.... >>> Ah, tasklets are pickled with a list of frames, that they then >>> re-assemble when unpickled. >>> >>> This is what confused me. I would have pickled frames as a linked >>> list, recursively. >>> I'm sure there is a good reason why they are pickled the way they >>> are :) >>> >>> K >>> >>>> -----Original Message----- >>>> From: [email protected] [mailto:stackless- >>>> [email protected]] On Behalf Of Richard Tew >>>> Sent: 6. mars 2014 07:34 >>>> To: The Stackless Python Mailing List >>>> Subject: Re: [Stackless] 3.2.5 unittest failure >>>> >>>> This is the blocker for the releases of 2.7.x, 3.2.x, 3.3.x and 3.4. >>>> >>>> Is this something that is a problem with the way we are pickling? >>>> Or is it >>>> related to how unpickling happens? >>>> >>>> Cheers, >>>> Richard. >>>> >>>> On 3/5/14, Kristján Valur Jónsson <[email protected]> wrote: >>>>> ok, I have fixed it and pushed a new version. >>>>> I don't quite understand, why are unpickled frames marked with >>>>> None in >>>>> their f_back? Does that mean that we never pickle frame stacks, but >>>>> only single frames? >>>>> I looked for other cases where we test for this None but didn't >>>>> find it... >>>>> K >>>>> >>>>>> -----Original Message----- >>>>>> From: [email protected] [mailto:stackless- >>>>>> [email protected]] On Behalf Of Richard Tew >>>>>> Sent: 3. mars 2014 07:32 >>>>>> To: [email protected] >>>>>> Subject: [Stackless] 3.2.5 unittest failure >>>>>> >>>>>> Kristjan, is it possible you missed a graft? >>>>>> >>>>>> This is the last line before a release build of 3.2.5 crashes for >>>>>> me: >>>>>> >>>>>> testCrasher (test_defects.TestCrashUponFrameUnpickling) ... >>>>>> >>>>>>> python32.dll!frame_getback(_frame * f=0x02836700, void * >>>>>> nope=0x00000000) Line 375 + 0x9 bytes C >>>>>> python32.dll!getset_get(PyGetSetDescrObject * >>>>>> descr=0x02069440, >>>>>> _object * obj=0x02836700, _object * type=0x1e2b03f8) Line 149 + >>>>>> 0x19 >>>>>> bytes C >>>>>> python32.dll!_PyObject_GenericGetAttrWithDict(_object * >>>>>> obj=0x02836700, _object * name=0x0205fe80, _object * >>>>>> dict=0x00000000) >>>>>> Line 988 + 0x12 bytes C >>>>>> python32.dll!PyObject_GenericGetAttr(_object * obj=0x02836700, >>>>>> _object * name=0x0205fe80) Line 1050 + 0xf bytes C >>>>>> python32.dll!PyObject_GetAttr(_object * v=0x02836700, >>>>>> _object * >>>>>> name=0x0205fe80) Line 835 + 0x10 bytes C >>>>>> python32.dll!PyEval_EvalFrame_value(_frame * f=0x027f56b8, int >>>>>> throwflag=506147444, _object * retval=0x1e2b3274) Line 2963 + 0x7 >>>>>> bytes C >>>>>> >>>>>> It crashes in: >>>>>> >>>>>> static PyObject * >>>>>> frame_getback(PyFrameObject *f, void *nope) { >>>>>> PyFrameObject *fb = f->f_back; >>>>>> PyObject *ret; >>>>>> while (fb != NULL && ! PyFrame_Check(fb)) >>>>>> fb = fb->f_back; >>>>>> >>>>>> Where fb = 0x03. >>>>>> >>>>>> Cheers, >>>>>> Richard. >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>> >>> _______________________________________________ >>> Stackless mailing list >>> [email protected] >>> http://www.stackless.com/mailman/listinfo/stackless >>> >> >> > -- Christian Tismer :^) <mailto:[email protected]> Software Consulting : Have a break! Take a ride on Python's Karl-Liebknecht-Str. 121 : *Starship* http://starship.python.net/ 14482 Potsdam : PGP key -> http://pgp.uni-mainz.de phone +49 173 24 18 776 fax +49 (30) 700143-0023 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/ _______________________________________________ Stackless mailing list [email protected] http://www.stackless.com/mailman/listinfo/stackless
