[Stackless] exceptions.TypeError: arg 5 (closure) expected cell, found stackless._wrap.cell when unpickling stackless thread

Crispin Wellington retrogradeorbit at gmail.com
Fri Oct 9 11:38:59 CEST 2009


Hi there,

I have written a server that contains stackless threads. When the server
shuts down these threads are serialised to disk. This all happens without
incident and I end up with a reasonably sized file per pickled object.

When I go to deserialise them I hit a problem. I get this...
-------------------
      File
"/home/cwellington/Development/yabi/yabi-be-twisted/trunk/TaskManager/Tasklets.py",
line 54, in load
        task = pickle.loads(data)
      File "/usr/local/stackless/lib/python2.6/pickle.py", line 1415, in
loads
        return Unpickler(file).load()
      File "/usr/local/stackless/lib/python2.6/pickle.py", line 898, in load
        dispatch[key](self)
      File "/usr/local/stackless/lib/python2.6/pickle.py", line 1258, in
load_build
        setstate(state)
    exceptions.TypeError: arg 5 (closure) expected cell, found
stackless._wrap.cell
--------------------

I think this might be a bug. The arguments are being passed back into the
constructor of the stackless._wrap.function and the constructor is throwing
that exception. So in essence, the __reduce__ or __reduce_ex__ functions are
creating instatiation values that do not work on reinstantiation.

I changed pickle.py to print out some debug. setstate is... <built-in method
__setstate__ of stackless._wrap.function object at 0x21ca0c8> and (state)[4]
is... (<cell at 0x2605f30: empty>, <cell at 0x2940718: list object at
0x259f518>, <cell at 0x2940670: str object at 0x2940768>, <cell at
0x2940750: str object at 0x29407d8>, <cell at 0x29407c0: int object at
0x25cd338>)

These all seem to be "cell" objects. Why aren't they (stackless._wrap.cell)
recognised as "cells"?

I can provide a pickletools.dis() dump of the pickle stream if wanted.

Using Stackless Python 2.6.2 on 64 bit linux (x86_64).

Can anybody help me decode my objects? or even find a way to encode them so
the are decodable? Is this a bug, or am I doing it wrong?

Kind regards

Crispin Wellington
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.stackless.com/pipermail/stackless/attachments/20091009/21d18cbf/attachment.htm>


More information about the Stackless mailing list