Re: Binding exception on Tiger

[James Walker]

Ken Thomases wrote:

On Aug 25, 2009, at 2:02 PM, James Walker wrote:

When my app ran on Tiger, there was an NSInvalidArgumentException with 
the reason:


"-observeValueForKeyPath:ofObject:change:context: only defined for 
abstract class.  Define -[NSCFString 
observeValueForKeyPath:ofObject:change:context:]!"


That seemed to happen when I had 2 enabled bindings on the same 
checkbox.  Is that a known limitation?


I don't think this has anything to do with having 2 bindings.

Notice the mention of NSCFString in the exception reason.  It appears 
that you have signed up some string object to receive KVO change 
notifications for some object's property.  Since NSCFString isn't 
equipped to handle receiving those notifications, you get an exception.  
The reason string is saying, "An object of class NSCFString has had 
-observeValueForKeyPath:ofObject:change:context: invoked on it.  This 
class didn't override that method, and so the base-class method 
implementation was invoked, and that implementation throws an exception 
telling you about the problem."


Of course, although it's advising you to implement an override of 
-observeValueForKeyPath:ofObject:change:context: on NSCFString, that's 
not what you really need to do.  You need to figure out why you 
subscribed a string object to receive such KVO change notifications in 
the first place.  It's almost certainly not what you meant to do.


One likely candidate is a memory management problem.  You may not have 
actually signed up a string object to receive such notifications.  



Not only did my code not sign up a string object for notifications, my 
code did not sign up ANY object for notifications.  So it has to involve 
bindings, doesn't it?  And getting rid of the cases where I had 2 enable 
bindings on one control made the problem go away.  (I guess I should 
have given more detail in my original post.)



Instead, you may have signed up some other object but allowed that 
object to deallocate itself by failing to retain it.  So, that object 
disappeared.  Later, a string object was allocated at the same memory 
location.  Now, it is receiving KVO change notifications it was never 
supposed to.  You can use NSZombie to diagnose this particular issue and 
learn which class of object was originally observing property changes.  
You can also use the Object Alloc instrument or malloc_history to learn 
where in your code that object was originally allocated.



Thanks for the idea, I'll try to remember about NSZombie if this problem 
crops up again.


Part of the problem is that my project is built with Xcode 3.1, which 
does not run on Tiger.  I tried to set up remote debugging, but had all 
sorts of trouble.  And by the way, Instruments, which you mention, 
doesn't run on Tiger either.

--
  James W. Walker, Innoventive Software LLC
  
___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Binding exception on Tiger

[Ken Thomases]

On Aug 25, 2009, at 2:02 PM, James Walker wrote:

When my app ran on Tiger, there was an NSInvalidArgumentException  
with the reason:


"-observeValueForKeyPath:ofObject:change:context: only defined for  
abstract class.  Define -[NSCFString  
observeValueForKeyPath:ofObject:change:context:]!"


That seemed to happen when I had 2 enabled bindings on the same  
checkbox.  Is that a known limitation?


I don't think this has anything to do with having 2 bindings.

Notice the mention of NSCFString in the exception reason.  It appears  
that you have signed up some string object to receive KVO change  
notifications for some object's property.  Since NSCFString isn't  
equipped to handle receiving those notifications, you get an  
exception.  The reason string is saying, "An object of class  
NSCFString has had -observeValueForKeyPath:ofObject:change:context:  
invoked on it.  This class didn't override that method, and so the  
base-class method implementation was invoked, and that implementation  
throws an exception telling you about the problem."


Of course, although it's advising you to implement an override of - 
observeValueForKeyPath:ofObject:change:context: on NSCFString, that's  
not what you really need to do.  You need to figure out why you  
subscribed a string object to receive such KVO change notifications in  
the first place.  It's almost certainly not what you meant to do.


One likely candidate is a memory management problem.  You may not have  
actually signed up a string object to receive such notifications.   
Instead, you may have signed up some other object but allowed that  
object to deallocate itself by failing to retain it.  So, that object  
disappeared.  Later, a string object was allocated at the same memory  
location.  Now, it is receiving KVO change notifications it was never  
supposed to.  You can use NSZombie to diagnose this particular issue  
and learn which class of object was originally observing property  
changes.  You can also use the Object Alloc instrument or  
malloc_history to learn where in your code that object was originally  
allocated.


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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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