Re: [Pyobjc-dev] the mysterious attribute error

[Ronald O. <ous...@ci...>]

On 28-mrt-04, at 18:36, Burris T. Ewell wrote:

> Another clue:
>
> *** malloc[5538]: error for object 0x5b9f00: Double free
>
> Somewhere, memory management is going awry.

That's consistent with my diagnosis. I'm thinking about a fix for this,  
but I have not yet found a good solution for this.

The problem is that __dict__ and attributes introduced by __slots__ are  
'PyObject*' attributes when you look at the object from Objective-C.  
These are copied by the default copyWithZone: but without updating the  
reference count (Py_INCREF-ing the value). That means we're hosed when  
copy/copyWithZone: is used, because it is not possible to fix the  
reference count using Python code.

It is easy enough to silently introduce a copyWithZone: method that  
does the right thing, but that won't work when someone tries to  
implement a copyWithZone: method in Python (e.g. for customizing the  
copy).

When someone adds 'def copyWithZone_(self, zone)' to a new class, we  
cannot insert the generic PyObjC-copyWithZone: implementation without  
either adding serious hacks, e.g. looking for calls to the super-class  
implementation of copyWithZone: and replacing them by calls to a helper  
function, or changing the semantics.

The best option seems to be to change the interface for copyWithZone_:  
if you implement copyWithZone_ in Python it must have the following  
interface:

	def copyWithZone_(self, zone, copy):
		# Update copy here
		return copy


I don't really like this, but don't see how we can have the normal  
semantics and yet be able to insert our own method into the call-chain.  
The reason I don't like this is that this interface can/should only be  
used when subclassing a class that implements NSCopying.

Luckily we can give a usefull error-message when someone does implement  
copyWithZone_ but doesn't use the right inteface.

Ronald

>
> burris
>
> On Mar 27, 2004, at 11:24 PM, Ronald Oussoren wrote:
>
>>
>> On 28-mrt-04, at 4:11, Burris T. Ewell wrote:
>>
>>> Okay, I've removed all of the threads from my application.  It's  
>>> completely kosher.  I use NSTasks for the workers, and DO for  
>>> callbacks.  It works just fine most of the time.  When I click  
>>> around between rows, especially when one or more rows are getting  
>>> frequent updates, I get the weird crash with the disappearing  
>>> attribute when the cell is redrawing.  A race condition that causes  
>>> objects to get decref'd?
>>
>> From Subclassing NSCell at  
>> http://developer.apple.com/documentation/Cocoa/Conceptual/ 
>> ControlCell/index.html#//apple_ref/doc/uid/10000015i:
>>
>> <quote>
>> If the subclass contains instance variables that hold pointers to  
>> objects, consider overriding copyWithZone: to duplicate the objects.  
>> The default version copies only pointers to the objects.
>> </quote>
>>
>> You should implemented copyWithZone: unless you subclass has  
>> '__slots__ = ()', otherwise the copy of a cell will share its  
>> __dict__ with the original, without updating the reference count.  
>> That will give problems later on.
>>
>> Ronald
>> --
>> X|support bv            http://www.xsupport.nl/
>> T:  +31 610271479       F:  +31 204416173
>>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>
>
--
X|support bv            http://www.xsupport.nl/
T:  +31 610271479       F:  +31 204416173