Re: iOS - the joy of observers and NSInternalInconsistancyException for KVO

[Roland King]

> On 20 May 2016, at 07:04, Roland King  wrote:
> 
> 
> Reading the original post he already has the warning about an object being 
> deallocated whilst still having observers attached to it. 
> 
> This is simply a case of putting a breakpoint on dealloc and working out why 
> the object is being deallocated before you’ve gone through the observation 
> removal code you have. 

.. and if you want a condition you can put on a conditional breakpoint inside 
dealloc (or swift equivalent), checking self.observationInfo != nil may help to 
get the right dealloc. And that object, even though it’s actually opaque and 
internal and not-to-be-used, when printed will reveal some hints about who is 
still observing you .. at least in objC, I’ve never got the right commands to 
make LLDB use the objC print to show it. 

Just for clarity - I’m not suggesting using observationInfo to ‘prevent 
dealloc’, which you can’t do anyway and even if you could would be somewhere 
just the other side of insane, just to help filter out during debugging which 
dealloc to break on. 
___

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: iOS - the joy of observers and NSInternalInconsistancyException for KVO

[Roland King]

> On 20 May 2016, at 04:36, Jens Alfke  wrote:
> 
> 
>> On May 19, 2016, at 1:24 PM, Alex Zavatone  wrote:
>> 
>> In this case, I'm trying to see what is causing this deallocation.  In my 
>> code, I explicitly remove the observer before I nil the object, so I don't 
>> know where this is happening.  
> 
> If you’re observing an object, you should probably establish a strong 
> reference to it, like by assigning it to an ivar or adding it to an array or 
> something. Otherwise you can’t guarantee that it will stay alive. But since 
> say “nil the object”, which I guess means “nil a variable pointing to the 
> object”, then you should already have a strong reference, so the object 
> shouldn’t get dealloced unless you’ve got a ref-counting error somewhere. (Do 
> you use ARC?)
> 
> There is a user default NSBindingDebugLogLevel on Mac OS that you can set to 
> 1, which will generate extra warnings about KVO and bindings. It might do 
> something useful in your case; I can’t remember exactly what it does, but it 
> may produce a warning when an object with observers gets dealloced.
> 
> —Jens

Reading the original post he already has the warning about an object being 
deallocated whilst still having observers attached to it. 

This is simply a case of putting a breakpoint on dealloc and working out why 
the object is being deallocated before you’ve gone through the observation 
removal code you have. 
___

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: iOS - the joy of observers and NSInternalInconsistancyException for KVO

[Jens Alfke]

> On May 19, 2016, at 1:24 PM, Alex Zavatone  wrote:
> 
> In this case, I'm trying to see what is causing this deallocation.  In my 
> code, I explicitly remove the observer before I nil the object, so I don't 
> know where this is happening.  

If you’re observing an object, you should probably establish a strong reference 
to it, like by assigning it to an ivar or adding it to an array or something. 
Otherwise you can’t guarantee that it will stay alive. But since say “nil the 
object”, which I guess means “nil a variable pointing to the object”, then you 
should already have a strong reference, so the object shouldn’t get dealloced 
unless you’ve got a ref-counting error somewhere. (Do you use ARC?)

There is a user default NSBindingDebugLogLevel on Mac OS that you can set to 1, 
which will generate extra warnings about KVO and bindings. It might do 
something useful in your case; I can’t remember exactly what it does, but it 
may produce a warning when an object with observers gets dealloced.

—Jens
___

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: iOS - the joy of observers and NSInternalInconsistancyException for KVO

[Alex Zavatone]

On May 19, 2016, at 2:10 PM, Jens Alfke wrote:

> 
>> On May 19, 2016, at 9:54 AM, Alex Zavatone  wrote:
>> 
>> OK, fair enough.  Looks like I'll have build a little weak referenced dealy 
>> that subclasses dealloc and stops if it detects any observers. 
> 
> Holy crap, don’t do that. First, you can’t stop a dealloc. Instead you’d have 
> to override retain and release, which is very tricky and will break ARC. 
> Second, needing to do this is a sure sign that You’re Doing It Wrong — it’s 
> like one of those images captioned FAIL where someone’s done some crime 
> against nature using duct tape.

I have no means to see why this is happening at this point.  If I have sinned 
against nature or if nature is sinning against me, I can't tell yet; duct tape 
be damned.

> What is the problem exactly? Who is observing what?

In this case, I'm trying to see what is causing this deallocation.  In my code, 
I explicitly remove the observer before I nil the object, so I don't know where 
this is happening.  

On iOS, part of my app downloads files over https using NSURLSession.  Not a 
problem.  In a manager class, I perform this operation "get the list of files 
from our web end point and then download everything one file at a time 
asynchronously".  I thought it would be fun to use KVO to observe when the 
downloaded file is saved into its final path and then iterate to the next item 
in the list. However, when I switch to one of our pre release web end points, 
we use self signed certs and I haven't had the time to implement the 
challenge/response code yet.  This causes the NSURLSession to clear itself 
somehow.  Now that a failure case has reared its ugly head, I'd like to know 
why the object is removing itself before I am removing the observer.

I want to catch the point where dealloc is being called and the object is still 
being observed, so I can see why this is happening on this failure case.

> —Jens

___

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: iOS - the joy of observers and NSInternalInconsistancyException for KVO

[Alex Zavatone]

Yeah, I have strong references too, but some part of my NSURLSession code ends 
up causing this error when we have a failure (SSL challenge) on a file download.

I'll have to implement the methods to handle the download failure cases, which 
I am currently not doing.

On May 19, 2016, at 12:57 PM, Jonathan Mitchell wrote:

> 
>> On 19 May 2016, at 17:55, Jonathan Mitchell  wrote:
>> 
>> That way the observed object can get deallocated before the observer.
> Should say 
> That way the observed object cannot get deallocated before the observer.
> 
> 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/zav%40mac.com
> 
> This email sent to z...@mac.com


___

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: iOS - the joy of observers and NSInternalInconsistancyException for KVO

[Jens Alfke]

> On May 19, 2016, at 9:54 AM, Alex Zavatone  wrote:
> 
> OK, fair enough.  Looks like I'll have build a little weak referenced dealy 
> that subclasses dealloc and stops if it detects any observers. 

Holy crap, don’t do that. First, you can’t stop a dealloc. Instead you’d have 
to override retain and release, which is very tricky and will break ARC. 
Second, needing to do this is a sure sign that You’re Doing It Wrong — it’s 
like one of those images captioned FAIL where someone’s done some crime against 
nature using duct tape.

What is the problem exactly? Who is observing what?

—Jens
___

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: iOS - the joy of observers and NSInternalInconsistancyException for KVO

[Jonathan Mitchell]

> On 19 May 2016, at 17:55, Jonathan Mitchell  wrote:
> 
> That way the observed object can get deallocated before the observer.
Should say 
That way the observed object cannot get deallocated before the observer.

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: iOS - the joy of observers and NSInternalInconsistancyException for KVO

[Jonathan Mitchell]

> 
> Is there any safer KVO technique to prevent or detect the dreaded "An 
> instance of xx was deallocated while key value observers were still 
> registered with it"?
> 
I have a ton of observers in NSViewController subclasses.
Generally when I use an observer I make 100% sure I have a strong property 
reference (held by the NSViewController instance) to the observed object.
That way I know that the observed object will live as long as the 
NSViewController.
That way the observed object can get deallocated before the observer.
I then always make sure to remove my observers in NSViewController -dealloc.

If you want the observer to stop observing on command then use a delegate 
pattern or a notification to explicitly request that.

It is a futile task IMHO to dig into the KVO machinery and try and second guess 
it.

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

Re: iOS - the joy of observers and NSInternalInconsistancyException for KVO

[Alex Zavatone]

On May 19, 2016, at 12:41 PM, Jens Alfke wrote:

> 
>> On May 19, 2016, at 7:51 AM, Alex Zavatone  wrote:
>> 
>> Is there a means to have an object know when it's being observed so that it 
>> will refuse to nuke itself in this condition?
> 
> Nope. Remember, objects don’t “nuke” themselves; they are dealloced when no 
> other objects have references to them. It’s the observer’s responsibility to 
> retain a reference to the target object (observee?) for as long as it’s 
> observing that object. Or at least to have some means of detecting that the 
> target object is going to go away, and removing itself as an observer then.
> 
> —Jens

OK, fair enough.  Looks like I'll have build a little weak referenced dealy 
that subclasses dealloc and stops if it detects any observers.  Then for any 
object that I plan on being KVOable, it will have to be be a subclass of 
NSObject+bubblewrappedKVO, if dealloc is called while observers are still on 
the object.

Thank you, sir.

Alex Zavatone
___

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: iOS - the joy of observers and NSInternalInconsistancyException for KVO

[Jens Alfke]

> On May 19, 2016, at 7:51 AM, Alex Zavatone  wrote:
> 
> Is there a means to have an object know when it's being observed so that it 
> will refuse to nuke itself in this condition?

Nope. Remember, objects don’t “nuke” themselves; they are dealloced when no 
other objects have references to them. It’s the observer’s responsibility to 
retain a reference to the target object (observee?) for as long as it’s 
observing that object. Or at least to have some means of detecting that the 
target object is going to go away, and removing itself as an observer then.

—Jens
___

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

iOS - the joy of observers and NSInternalInconsistancyException for KVO

[Alex Zavatone]

I'm having fun with async NSURLSession downloads but running into objects 
deleting themselves in error cases while still being observed, resulting in the 
lovely NSInternalInconsistancyException.

Is there a means to have an object know when it's being observed so that it 
will refuse to nuke itself in this condition?

Sure, I can set a breakpoint on dealloc to see when this is happening, but I'm 
sure you lots of people have already run into this condition and have already 
figured out how to handle it.

Is there any safer KVO technique to prevent or detect the dreaded "An instance 
of xx was deallocated while key value observers were still registered with 
it"?

Thanks in advance,

Alex Zavatone
___

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