Re: KVO strangeness under 10.5
Re: KVO strangeness under 10.5
- Subject: Re: KVO strangeness under 10.5
- From: Mark Piccirelli <email@hidden>
- Date: Sun, 13 Apr 2008 15:44:04 -0700
Sean --
Nothing in KVO's guts registers arrays as observers, and nothing in
Cocoa Bindings either as far as I know.
For the curious, NSKeyValueObservances are instances of an internal
class that gets instantiated and put in the observation info of
observed object. (Hugely subject to change; no one should write apps
that depend on these details.) In 10.5 they are also used as observers
when key paths are being observed. For example, the observance for an
object's "category.color" is itself an observer of the "color" of the
object's current "category" and forwards notifications to the ultimate
observer. When the object's "category" changes it also removes itself
as an observer the old value's "color" and adds itself as an observer
of the new value before sending the notification to the ultimate
observer. So, it makes sense that you're seeing NSKeyValueObservances
as observers.
One possible cause of what you're seeing might be bad KVO-compliance
for "category." If KVO itself doesn't get notified of changes to that
value the machinery just described gets pretty confused. There are
exceptions thrown for many instances of that mistake but perhaps not
all.
Anyway, an app that works on 10.4 but not on 10.5 always smells like a
backward binary incompatibility in our stuff regardless of where the
actual programming mistake is. Please file a bug report with
instructions on how to reproduce this problem. Hopefully your app is
something you can attach or point us to. Thanks…
-- Mark
On Apr 13, 2008, at 1:35 PM, Sean Todd wrote:
Thanks Mark (and Jim) for the NSZombieEnabled/NSDeallocateZombies
reminder. This showed me that the object has indeed been deallocated
by the time that breakpoint was reached.
Setting an earlier breakpoint I was able to get some more
information on this unknown observer:
<NSKeyValueObservance 0x6207300: Observer: 0x620c180, Key path:
grade, Options: <New: NO, Old: NO, Prior: NO> Context: 0x1e00b0,
Property: 0x1e1040>
)
(gdb) po 0x620c180
<NSCFArray 0x620c180>(
<NSKeyValueObservance 0x1f0f90: Observer: 0x182180, Key path: color,
Options: <New: NO, Old: NO, Prior: NO> Context: 0x1e6450, Property:
0x1e2ca0>
)
So this object is some array that contains single
NSKeyValueObservance. Following the trail of observers shows:
(gdb) po 0x182180
<NSKeyValueObservance 0x182180: Observer: 0x62005f0, Key path:
category.color, Options: <New: NO, Old: NO, Prior: NO> Context: 0x0,
Property: 0x62059d0>
(gdb) po 0x62005f0
<NSTableBinder: 0x62005f0>{object: <NSTableView: 0x1ee580>,
bindings: content=arrangedObjects,
selectionIndexes=selectionIndexes, sortDescriptors=sortDescriptors}
Unfortunately, I am still puzzled by how/why this array is set as an
observer.
Setting a breakpoint with -addObserver:... (as suggested by Chuck
Steinman) did not help as gdb could not provide any data via info
args when this breakpoint was hit.
I am sure that this is due to changes in the KVO system in 10.5 but
not sure if this is revealing a bug in that system or uncovering a
problem with my use of KVO (perhaps some workaround code to a
problem with KVO and bindings pre-10.5).
On Apr 12, 2008, at 7:42 PM, Mark Piccirelli wrote:
Yikes, that's not good. I'd try running with NSZombieEnable = YES
to see if that turns up anything. That should also set
NSDeallocateZombies = NO, which might make gdb po work.
-- Mark
On Apr 12, 2008, at 5:14 PM, Sean Todd wrote:
Unfortunately, that doesn't work:
<NSKeyValueObservance 0x65009d0: Observer: 0x6500210, Key path:
grade, Options: <New: NO, Old: NO, Prior: NO> Context: 0x1957c0,
Property: 0x18edf0>
)
(gdb) po 0x6500210
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0xc007391b
0xfffeff18 in objc_msgSend_rtp ()
The program being debugged was signaled while in a function called
from GDB.
GDB has restored the context to what it was before the call.
To change this behavior use "set unwindonsignal off"
Evaluation of the expression containing the function
(_NSPrintForDebugger) will be abandoned.
On Apr 12, 2008, at 5:18 PM, Mark Piccirelli wrote:
You can copy-and-paste to find out what the surprising observers
are, as in:
(gdb) po 0x19e5a0
-- Mark
On Apr 12, 2008, at 2:59 PM, Sean Todd wrote:
I have a Cocoa document app that uses bindings. After installing
10.5 and Xcode 3.0, I started seeing console output stating that
objects were being deallocated while observers are still
registered with them. After some investigation, I found that the
objects being deallocated had an extra observer that I never
registered (see the final observance instance listed in the -
observationInfo output below:
(gdb) po [theItem observationInfo]
<NSKeyValueObservationInfo 0x1e3880> (
<NSKeyValueObservance 0x19e5a0: Observer: 0x18ea60, Key path:
name, Options: <New: NO, Old: YES, Prior: NO> Context: 0x0,
Property: 0x19e5c0>
<NSKeyValueObservance 0x1a3ca0: Observer: 0x18ea60, Key path:
category, Options: <New: NO, Old: YES, Prior: NO> Context: 0x0,
Property: 0x1a3c80>
<NSKeyValueObservance 0x1ce8b0: Observer: 0x18ea60, Key path:
grade, Options: <New: YES, Old: YES, Prior: NO> Context: 0x0,
Property: 0x192920>
<NSKeyValueObservance 0x1ceb50: Observer: 0x18ea60, Key path:
isDropped, Options: <New: NO, Old: YES, Prior: NO> Context: 0x0,
Property: 0x1a3cd0>
<NSKeyValueObservance 0x192340: Observer: 0x193060, Key path:
grade, Options: <New: NO, Old: YES, Prior: NO> Context: 0x0,
Property: 0x192920>
<NSKeyValueObservance 0x65046c0: Observer: 0x6503f00, Key path:
grade, Options: <New: NO, Old: NO, Prior: NO> Context: 0x18ea60,
Property: 0x192920>
)
I have no idea what sort of object 0x6503f00 is or how/when it
was registered. Looking at the address in memory did not give me
any clues. The one interesting bit of info is that the address
listed with its Context is the same as the first 4 observers.
Continuing on predictably leads to the console output:
2008-04-12 16:18:20.760 MyApp[329:813] An instance 0x1c3d40 of
class Assignment is being deallocated while key value observers
are still registered with it. Observation info is being leaked,
and may even become mistakenly attached to some other object.
Set a breakpoint on NSKVODeallocateBreak to stop here in the
debugger. Here's the current observation info:
<NSKeyValueObservationInfo 0x1b3970> (
<NSKeyValueObservance 0x6503f20: Observer: 0x6503f00, Key path:
grade, Options: <New: NO, Old: NO, Prior: NO> Context: 0x1c3ce0,
Property: 0x192920>
)
When I debug this app with Xcode 2.4 on 10.4.x, there are no
extra observers and everything works well.
I did not see anything addressing this issue in the foundation
release notes. Nor have I found any discussion of this problem
in the archives. Am I missing something? Do I need to file a
bug? Any help would be appreciated.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden