Re: KVO strangeness under 10.5

FROM : Sean Todd
DATE : Sun Apr 13 22:35:57 2008

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_removed>)
>>>>
>>>> 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/<email_removed>
>>>>
>>>> This email sent to <email_removed>

>>>

>>

>