Right, good point. Recently on python-dev, I saw people discussing that frame objects ought to be at least partially constructable from python. One of the reasons was that traceback objects rely on actual frames, not duck type frames, so one cannot construct artificial tracebacks, and other such annoying things.
The "none" for an unpickled frame should only ever be visible for a short time, because unpickled frames are usually linked and put into a tasklet. Hm, maybe the final "None" at the end of the chain remains. An oddidy, for sure. K > -----Original Message----- > From: [email protected] [mailto:stackless- > [email protected]] On Behalf Of Anselm Kruis > Sent: 11. mars 2014 10:29 > To: [email protected] > Subject: Re: [Stackless] 3.2.5 unittest failure > > 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 > >> > > > > > > -- > Dipl. Phys. Anselm Kruis science + computing ag > Senior Solution Architect Ingolstädter Str. 22 > email [email protected] 80807 München, Germany > phone +49 89 356386 874 fax 737 www.science-computing.de > -- > Vorstandsvorsitzender/Chairman of the board of management: > Gerd-Lothar Leonhart > Vorstand/Board of Management: > Dr. Bernd Finkbeiner, Michael Heinrichs, Dr. Arno Steitz, Dr. Ingrid Zech > Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: > Philippe Miltin > Sitz/Registered Office: Tuebingen > Registergericht/Registration Court: Stuttgart Registernummer/Commercial > Register No.: HRB 382196 > _______________________________________________ > Stackless mailing list > [email protected] > http://www.stackless.com/mailman/listinfo/stackless _______________________________________________ Stackless mailing list [email protected] http://www.stackless.com/mailman/listinfo/stackless
