Re: firstResponder KVO snow leopard crash; bug?
On Nov 18, 2009, at 5:28 PM, Aaron Clarke wrote:
>
> On Nov 18, 2009, at 12:00 , Corbin Dunn wrote:
>
>>
>> On Nov 17, 2009, at 1:04 PM, Aaron Clarke wrote:
>>
>>> We have an application that runs fine on leopard (10.5) but occasionally
>>> crashes on snow leopard (10.6) when closing an NSWindow. Here is the
>>> backtrace for the crash:
>>>
>>> Program received signal EXC_BAD_ACCESS, Could not access memory.
>>> Reason: KERN_PROTECTION_FAILURE at address: 0x
>>> 0x976e691b in objc_msgSend ()
>>> (gdb) bt
>>> #0 0x976e691b in objc_msgSend ()
>>> #1 0x197142d0 in ?? ()
>>> #2 0x9031e88e in NSKeyValuePushPendingNotificationPerThread ()
>>> #3 0x9031e224 in NSKeyValueWillChange ()
>>> #4 0x9030350b in -[NSObject(NSKeyValueObserverNotification)
>>> willChangeValueForKey:] ()
>>> #5 0x90327cfe in _NSSetObjectValueAndNotify ()
>>> #6 0x92745fb8 in -[NSWindow makeFirstResponder:] ()
>>> ...
>>>
>>> Even if it doesn't crash, closing the NSWindow always results in the
>>> following error message.
>>>
>>> An instance 0x11b75230 of class MyWindow was deallocated while key value
>>> observers were still registered with it. Observation info was 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:
>>> (
>>> >> firstResponder, Options: Context: 0x0,
>>> Property: 0x4453e60>
>>> >> firstResponder, Options: Context: 0x0,
>>> Property: 0x4453e60>
>>> )
>>>
>>> I looked at what the observer object's class is, and it's a subclass of
>>> NSCollectionView. We do not explicitly setup a KVO relationship for
>>> firstResponder. I also noticed that the "Application Kit Release Notes for
>>> Snow Leopard" mention that firstResponder is KVO-compliant, which makes me
>>> believe this is something new in Snow Leopard. All this information makes
>>> me believe this is potentially a bug in Application Kit for 10.6. Maybe we
>>> setup an NSCollectionView incorrectly or I'm misinterpreting this
>>> information?
>>
>> Oh -- another thing. Does your subclass of NSCollectionView override:
>>
>> (void)viewWillMoveToWindow:(NSWindow *)window {
>>
>> but not call super? If not... call super! Your classes should always call
>> super if it is defined in a superclass, unless you have a good reason to
>> hide the super's behavior.
>>
>> corbin
>>
>>
>>
>>
>
> This was the problem, thank you. This is a difficult bug to find in code
> someone else wrote. This makes me almost wish there was a gcc flag for it
> (-Woverride-no-super).
FWIW, this is a compatibility problem we (AppKit) try to avoid. An update to
the OS shouldn't break one's app. Right now it is (obviously) too late to
change AppKit for SnowLeopard, but please do log a bug so we can "do something"
about it (it will probably amount to a tech note or release note or
documentation change for NSCollectionView).
corbin
___
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: firstResponder KVO snow leopard crash; bug?
On Nov 18, 2009, at 5:06 PM, Sean McBride wrote:
> On 11/18/09 9:00 AM, Corbin Dunn said:
>
>> Oh -- another thing. Does your subclass of NSCollectionView override:
>>
>> (void)viewWillMoveToWindow:(NSWindow *)window {
>>
>> but not call super? If not... call super! Your classes should always
>> call super if it is defined in a superclass, unless you have a good
>> reason to hide the super's behavior.
>
> Corbin,
>
> This comment caught by eye. As a general principle, I certainly agree
> with your comment.
>
> But I never call super when I override those methods, and I guess I
> should be doing so. Does NSView's implementation do something or only
> NSCollectionView?
Only NSCollectionView. But, that is a good question; how would one know they
should call super? In general, I think people should *always* call super,
unless they have some specific reason not to. Assuming that super may or may
not do anything is simply an implementation detail -- in the future we may add
code that does something.
Maybe for this case we should add the declaration to NSCollectionView and state
that it overrides the method to do more work. The .NET framework tends to do
this to let people know when that happens, and it might be nice for AppKit to
do it too.
>
> The docs often comment about calling super. In NSView's case, they do
> for beginDocument, beginPageInRect:atPlacement:, drawRect:, endDocument,
> viewWillStartLiveResize, etc. but they don't for the
> viewWillMoveToWindow:. I guess I'm so used to seeing a comment, that if
> I don't see one, I don't call super. At least one Apple example also doesn't:
> EventOverview/MouseTrackingEvents/MouseTrackingEvents.html>
>
> Should one call super for all the viewWill/Did methods?
My opinion is yes. Please log a documentation bug asking to be clarified (you
can copy my email into it).
corbin
___
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: firstResponder KVO snow leopard crash; bug?
Aaron Clarke (clark...@gmail.com) on 2009-11-18 8:28 PM said:
>> Oh -- another thing. Does your subclass of NSCollectionView override:
>>
>> (void)viewWillMoveToWindow:(NSWindow *)window {
>>
>> but not call super? If not... call super! Your classes should always
>> call super if it is defined in a superclass, unless you have a good
>> reason to hide the super's behavior.
>>
>> corbin
>
>This was the problem, thank you. This is a difficult bug to find in
>code someone else wrote. This makes me almost wish there was a gcc
>flag for it (-Woverride-no-super).
You will get such a warning if you fail to call super in dealloc and
finalize. Expanding that to more methods should be possible I guess...
maybe a job for the clang static analyzer. Do file a bug.
Sean
___
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: firstResponder KVO snow leopard crash; bug?
On Nov 18, 2009, at 12:00 , Corbin Dunn wrote:
On Nov 17, 2009, at 1:04 PM, Aaron Clarke wrote:
We have an application that runs fine on leopard (10.5) but
occasionally
crashes on snow leopard (10.6) when closing an NSWindow. Here is the
backtrace for the crash:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x
0x976e691b in objc_msgSend ()
(gdb) bt
#0 0x976e691b in objc_msgSend ()
#1 0x197142d0 in ?? ()
#2 0x9031e88e in NSKeyValuePushPendingNotificationPerThread ()
#3 0x9031e224 in NSKeyValueWillChange ()
#4 0x9030350b in -[NSObject(NSKeyValueObserverNotification)
willChangeValueForKey:] ()
#5 0x90327cfe in _NSSetObjectValueAndNotify ()
#6 0x92745fb8 in -[NSWindow makeFirstResponder:] ()
...
Even if it doesn't crash, closing the NSWindow always results in the
following error message.
An instance 0x11b75230 of class MyWindow was deallocated while key
value
observers were still registered with it. Observation info was
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:
(
Context: 0x0,
Property: 0x4453e60>
Context: 0x0,
Property: 0x4453e60>
)
I looked at what the observer object's class is, and it's a
subclass of
NSCollectionView. We do not explicitly setup a KVO relationship for
firstResponder. I also noticed that the "Application Kit Release
Notes for
Snow Leopard" mention that firstResponder is KVO-compliant, which
makes me
believe this is something new in Snow Leopard. All this
information makes
me believe this is potentially a bug in Application Kit for 10.6.
Maybe we
setup an NSCollectionView incorrectly or I'm misinterpreting this
information?
Oh -- another thing. Does your subclass of NSCollectionView override:
(void)viewWillMoveToWindow:(NSWindow *)window {
but not call super? If not... call super! Your classes should always
call super if it is defined in a superclass, unless you have a good
reason to hide the super's behavior.
corbin
This was the problem, thank you. This is a difficult bug to find in
code someone else wrote. This makes me almost wish there was a gcc
flag for it (-Woverride-no-super).
-Aaron
___
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: firstResponder KVO snow leopard crash; bug?
On 11/18/09 9:00 AM, Corbin Dunn said:
>Oh -- another thing. Does your subclass of NSCollectionView override:
>
> (void)viewWillMoveToWindow:(NSWindow *)window {
>
>but not call super? If not... call super! Your classes should always
>call super if it is defined in a superclass, unless you have a good
>reason to hide the super's behavior.
Corbin,
This comment caught by eye. As a general principle, I certainly agree
with your comment.
But I never call super when I override those methods, and I guess I
should be doing so. Does NSView's implementation do something or only
NSCollectionView?
The docs often comment about calling super. In NSView's case, they do
for beginDocument, beginPageInRect:atPlacement:, drawRect:, endDocument,
viewWillStartLiveResize, etc. but they don't for the
viewWillMoveToWindow:. I guess I'm so used to seeing a comment, that if
I don't see one, I don't call super. At least one Apple example also doesn't:
Should one call super for all the viewWill/Did methods?
Thanks,
--
Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com
Mac Software Developer Montréal, Québec, Canada
___
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: firstResponder KVO snow leopard crash; bug?
On Nov 17, 2009, at 1:04 PM, Aaron Clarke wrote:
> We have an application that runs fine on leopard (10.5) but occasionally
> crashes on snow leopard (10.6) when closing an NSWindow. Here is the
> backtrace for the crash:
>
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_PROTECTION_FAILURE at address: 0x
> 0x976e691b in objc_msgSend ()
> (gdb) bt
> #0 0x976e691b in objc_msgSend ()
> #1 0x197142d0 in ?? ()
> #2 0x9031e88e in NSKeyValuePushPendingNotificationPerThread ()
> #3 0x9031e224 in NSKeyValueWillChange ()
> #4 0x9030350b in -[NSObject(NSKeyValueObserverNotification)
> willChangeValueForKey:] ()
> #5 0x90327cfe in _NSSetObjectValueAndNotify ()
> #6 0x92745fb8 in -[NSWindow makeFirstResponder:] ()
> ...
>
> Even if it doesn't crash, closing the NSWindow always results in the
> following error message.
>
> An instance 0x11b75230 of class MyWindow was deallocated while key value
> observers were still registered with it. Observation info was 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:
> (
> firstResponder, Options: Context: 0x0,
> Property: 0x4453e60>
> firstResponder, Options: Context: 0x0,
> Property: 0x4453e60>
> )
>
> I looked at what the observer object's class is, and it's a subclass of
> NSCollectionView. We do not explicitly setup a KVO relationship for
> firstResponder. I also noticed that the "Application Kit Release Notes for
> Snow Leopard" mention that firstResponder is KVO-compliant, which makes me
> believe this is something new in Snow Leopard. All this information makes
> me believe this is potentially a bug in Application Kit for 10.6. Maybe we
> setup an NSCollectionView incorrectly or I'm misinterpreting this
> information?
Oh -- another thing. Does your subclass of NSCollectionView override:
(void)viewWillMoveToWindow:(NSWindow *)window {
but not call super? If not... call super! Your classes should always call super
if it is defined in a superclass, unless you have a good reason to hide the
super's behavior.
corbin
___
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: firstResponder KVO snow leopard crash; bug?
On Nov 17, 2009, at 1:04 PM, Aaron Clarke wrote: > We have an application that runs fine on leopard (10.5) but occasionally > crashes on snow leopard (10.6) when closing an NSWindow. Here is the > backtrace for the crash: > > Program received signal EXC_BAD_ACCESS, Could not access memory. > Reason: KERN_PROTECTION_FAILURE at address: 0x > 0x976e691b in objc_msgSend () > (gdb) bt > #0 0x976e691b in objc_msgSend () > #1 0x197142d0 in ?? () > #2 0x9031e88e in NSKeyValuePushPendingNotificationPerThread () > #3 0x9031e224 in NSKeyValueWillChange () > #4 0x9030350b in -[NSObject(NSKeyValueObserverNotification) > willChangeValueForKey:] () > #5 0x90327cfe in _NSSetObjectValueAndNotify () > #6 0x92745fb8 in -[NSWindow makeFirstResponder:] () > ... > > Even if it doesn't crash, closing the NSWindow always results in the > following error message. > > An instance 0x11b75230 of class MyWindow was deallocated while key value > observers were still registered with it. Observation info was 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: > ( > firstResponder, Options: Context: 0x0, > Property: 0x4453e60> > firstResponder, Options: Context: 0x0, > Property: 0x4453e60> > ) > > I looked at what the observer object's class is, and it's a subclass of > NSCollectionView. We do not explicitly setup a KVO relationship for > firstResponder. I also noticed that the "Application Kit Release Notes for > Snow Leopard" mention that firstResponder is KVO-compliant, which makes me > believe this is something new in Snow Leopard. All this information makes > me believe this is potentially a bug in Application Kit for 10.6. Maybe we > setup an NSCollectionView incorrectly or I'm misinterpreting this > information? Your window might be doing something strange, and causing notifications to be suppressed some how. What code does MyWindow have in it? corbin ___ 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: firstResponder KVO snow leopard crash; bug?
On Nov 17, 2009, at 2:04 PM, Aaron Clarke wrote: > Even if it doesn't crash, closing the NSWindow always results in the > following error message. > > An instance 0x11b75230 of class MyWindow was deallocated while key value > observers were still registered with it. Observation info was 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: > ( > firstResponder, Options: Context: 0x0, > Property: 0x4453e60> > firstResponder, Options: Context: 0x0, > Property: 0x4453e60> > ) Do you have "release when closed" checked for the window? If so, what happens when you uncheck it? HTH, Keary Suska Esoteritech, Inc. "Demystifying technology for your home or business" ___ 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
