On 19-mei-2006, at 16:34, Ronald Oussoren wrote:
> On 19-mei-2006, at 16:19, Luc Heinrich wrote:
>> On 19 mai 06, at 13:14, Luc Heinrich wrote:
>>> I just spent two days tracking down a weird (and bad) crash in my
>>> PyObjC application, which turns out to be a problem of pickling
>>> (using cPickle, fwiw) an instance of what I thought was a python
>>> float but which actually is a objc._pythonify.OC_PythonFloat.
>> Here's a contrived example to reproduce the crash:
>> from cPickle import dumps
>> from PyObjCTools import Conversion
>> from Foundation import NSMutableDictionary
>> d = NSMutableDictionary.alloc().init()
>> d.setObject_forKey_(42.0, "answer")
>> d = Conversion.pythonCollectionFromPropertyList(d)
>> p = dumps(d) # <--- BOOOOOOM, segfault!
> I get the same crash (both using python 2.3.5 and the latest-and-
> greated version of 2.5a). This is likely to be a bug in python
> itself, I'll have a look.
It's a python bug alright. The script below also crashes:
from cPickle import dumps
raise TypeError, "go away"
__slot__ = ('orig')
def __new__(cls, orig, value):
self = float.__new__(cls, value)
self.orig = orig
__class__ = property(lambda self: self.orig.__class__)
f = MyFloat(foo(), 1.0)
p = dumps(f)
The crash goes away if you remove the __reduce__ method. I haven't
hunted down the problem yet, but it a reduce method that raises an
exception on an object that lies about its __class__ seems to be the
I'm going to file a bug at python.org. I'll also check in a change to
pyobjc that works around this problem, and implements a more sane
behaviour (that is excludes the ObjC state from the pickle).
> Using Tomcat but need to do more? Need to support web services,
> Get stuff done quickly with pre-integrated technology to make your
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache
> Pyobjc-dev mailing list