KVO strangeness under 10.5
-
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. -
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. -
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.
> -
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.
>>
> -
On Apr 12, 2008, at 8: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.
Consider setting NSZombieEnabled=YES, NSDeallocateZombies=NO then
debug the problem. It is possible the observer has already been
deallocated (but was never removed as an observer.)
Jim -
--- Sean Todd <seantodd...> wrote:> 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.
Have you tried setting a breakpoint on addObserver:...
to see how and when it's being registered?
Cheers,
Chuck
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com -
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.
>>>
>>
> -
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.
>>>>
>>>
>>
>
