[Stackless] 3.2.5 unittest failure
Christian Tismer
tismer at stackless.com
Wed Mar 12 17:56:06 CET 2014
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-bounces at stackless.com [mailto:stackless-
>> bounces at stackless.com] On Behalf Of Anselm Kruis
>> Sent: 11. mars 2014 10:29
>> To: stackless at 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-bounces at stackless.com [mailto:stackless-
>>>>> bounces at 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 <kristjan at 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-bounces at stackless.com [mailto:stackless-
>>>>>>> bounces at stackless.com] On Behalf Of Richard Tew
>>>>>>> Sent: 3. mars 2014 07:32
>>>>>>> To: stackless at 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 at stackless.com
>>>>>>> http://www.stackless.com/mailman/listinfo/stackless
>>>>>> _______________________________________________
>>>>>> 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
>>>> _______________________________________________
>>>> Stackless mailing list
>>>> Stackless at 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.Kruis at 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 at stackless.com
>> http://www.stackless.com/mailman/listinfo/stackless
> _______________________________________________
> Stackless mailing list
> Stackless at stackless.com
> http://www.stackless.com/mailman/listinfo/stackless
--
Christian Tismer :^) <mailto:tismer at 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/
More information about the Stackless
mailing list