Hi friends, what is wrong or odd with the first frame of a frame list remaining None? From the tasklet's POV this is perfectly fine I think, because the pickled tasklet cannot know it's parent frame.
But we can redesign this to support tracebacks, although I don't understand completely what the problem is. Is the toplevel frame's f_back a NULL? If it's just that, well change it at reconstruction time. What crashes? Maybe we need to look into generator pickling... cheers - Chris On 11.03.14 15:24, Kristján Valur Jónsson wrote: > 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: stackless-boun...@stackless.com [mailto:stackless- >> boun...@stackless.com] On Behalf Of Anselm Kruis >> Sent: 11. mars 2014 10:29 >> To: stackless@stackless.com >> 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: stackless-boun...@stackless.com [mailto:stackless- >>>>> boun...@stackless.com] 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 <krist...@ccpgames.com> 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: stackless-boun...@stackless.com [mailto:stackless- >>>>>>> boun...@stackless.com] On Behalf Of Richard Tew >>>>>>> Sent: 3. mars 2014 07:32 >>>>>>> To: stackless@stackless.com >>>>>>> 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 >>>>>>> Stackless@stackless.com >>>>>>> http://www.stackless.com/mailman/listinfo/stackless >>>>>> _______________________________________________ >>>>>> Stackless mailing list >>>>>> Stackless@stackless.com >>>>>> http://www.stackless.com/mailman/listinfo/stackless >>>>>> >>>>> _______________________________________________ >>>>> Stackless mailing list >>>>> Stackless@stackless.com >>>>> http://www.stackless.com/mailman/listinfo/stackless >>>> _______________________________________________ >>>> Stackless mailing list >>>> Stackless@stackless.com >>>> http://www.stackless.com/mailman/listinfo/stackless >>>> >>> >> -- >> Dipl. Phys. Anselm Kruis science + computing ag >> Senior Solution Architect Ingolstädter Str. 22 >> email a.kr...@science-computing.de 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 >> Stackless@stackless.com >> http://www.stackless.com/mailman/listinfo/stackless > _______________________________________________ > Stackless mailing list > Stackless@stackless.com > http://www.stackless.com/mailman/listinfo/stackless -- Christian Tismer :^) <mailto:tis...@stackless.com> 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 Stackless@stackless.com http://www.stackless.com/mailman/listinfo/stackless
