Re: KVO - deallocation with observers attached

[Jonathan Mitchell]

> On 1 Jun 2017, at 00:51, Ken Thomases  wrote:
> 
> On May 31, 2017, at 5:02 PM, Jonathan Mitchell  wrote:
>> 
>> It is common for deallocating objects to abort if they have observers still 
>> registered.
>> 
>> The Data_Test object is deallocated with non nil -observationInfo and yet it 
>> does not abort.
>> Why does this occur?
> 
> It's not clear to me that the KVO machinery is obligated to set 
> observationInfo to nil when an object is no longer being observed.  Note that 
> observationInfo is *not* an object pointer.  It's a pointer to void.  Among 
> other things, that means that there's no memory management involved in the 
> setter.  That is, it's not a strong reference or even a weak one.  So, for 
> example, it's not necessary for KVO to nil it out to free memory.

Thanks for the input.
I wasn’t able to get to the bottom of this despite poking around with Hopper 
through the foundation framework.
There is an NSKVODeallocate foundation function that can get called when an 
observed object gets deallocated.
It raises the familiar KVO exception if -observationInfo is not nil.

- observationInfo does return a void* but it dereferences to an 
NSKeyValueObservationInfo :  NSObject instance.
Its obviously private API though.

I was able to track the comings and goings of NSKeyValueObservationInfo using 
the memory graph debugger and malloc stack logging but enlightenment did not 
strike.

I was able to make my test project behave as I anticipated but my real world 
app doesn’t seem so compliant.

I am just trying to eradicate the possibility of crashes that occur when the 
observing object deallocs and the observed object keeps pumping notifications 
to the old observers address.

Thanks

J

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: KVO - deallocation with observers attached

[Ken Thomases]

On May 31, 2017, at 5:02 PM, Jonathan Mitchell  wrote:
> 
> It is common for deallocating objects to abort if they have observers still 
> registered.
> 
> However in some cases it seems that an object can get deallocated with 
> observers attached and not abort.
> 
> I have instrumented my test case thoroughly and overridden 
> -setObservationInfo: to log the observation changes as below.
> 
> The Data_Test object is deallocated with non nil -observationInfo and yet it 
> does not abort.
> Why does this occur?

It's not clear to me that the KVO machinery is obligated to set observationInfo 
to nil when an object is no longer being observed.  Note that observationInfo 
is *not* an object pointer.  It's a pointer to void.  Among other things, that 
means that there's no memory management involved in the setter.  That is, it's 
not a strong reference or even a weak one.  So, for example, it's not necessary 
for KVO to nil it out to free memory.

That also means that you should not be logging the observationInfo as though it 
were an object (using the "%@" format specifier or otherwise sending the 
-description message to it).  As mentioned in the observationInfo docs, 
"Overrides of this property must not attempt to send messages to the stored 
data."

By the way, does your override just log and call through to super?  Or did you 
actually implement storage in an instance variable?  If you did the latter, 
it's conceivable that you changed whether or not crashes are likely to follow 
deallocation with observers.  That's because the observationInfo would not be 
stored in a global look-aside table such that it could get accidentally 
attached to an unrelated object that happened to be allocated at the same 
address.

> I am sorting through some observer related crash reports just trying to 
> figure out possible causes.

I would think you'd have better luck logging the addition and removal of 
observers looking for an imbalance.

Regards,
Ken

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

KVO - deallocation with observers attached

[Jonathan Mitchell]

It is common for deallocating objects to abort if they have observers still 
registered.

However in some cases it seems that an object can get deallocated with 
observers attached and not abort.

I have instrumented my test case thoroughly and overridden -setObservationInfo: 
to log the observation changes as below.

The Data_Test object is deallocated with non nil -observationInfo and yet it 
does not abort.
Why does this occur?

I am sorting through some observer related crash reports just trying to figure 
out possible causes.

The Data_Test object is heavily observed throughout its lifetime both by 
bindings and explicit observations.

macOS 10.12

2017-05-31 22:49:01.616632+0100 MyApp Data_Test (0x11336d100) SetObservationInfo
2017-05-31 22:49:01.616656+0100 MyApp oldObservationInfo : 
 (
 Context: 0x10075a4b8, Property: 
0x6144abc0>
 
Context: 0x0, Property: 0x608000a51280>
)
2017-05-31 22:49:01.616692+0100 MyApp newObservationInfo : 
 (
 Context: 0x10075a4b8, Property: 
0x6144abc0>
)
2017-05-31 22:49:04.188226+0100 MyApp Data_Test (0x11336d100) dealloc

Thanks

Jonathan
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com