Re: KVO strangeness under 10.5
Re: KVO strangeness under 10.5
- Subject: Re: KVO strangeness under 10.5
- From: Sean Todd <email@hidden>
- Date: Sun, 13 Apr 2008 15:35:57 -0500
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