Non-document app's NSWindow keeps getting retained
-
I've got a Cocoa app that manually creates an NSWindow (it's an
easier fit for a cross-platform engine). From my debugging, it
appears that every time I click another app's window, the retain
count on my NSWindow goes up by 2 (I have a windowDidResignKey
delegate which prints the retain count). I don't make an
NSWindowController.
If I override -[NSApplication windows] and return an empty array, the
regain count doesn't keep climbing. This seems kind of odd.
The behavior is happening on 10.4.11 and 10.5.1.
I suspect I must be doing something wrong, but can't figure out what.
David Dunham
Voice/Fax: 206 783 7404 http://www.pensee.com/dunham/
Imagination is more important than knowledge. -- Albert Einstein -
On 5 Feb 2008, at 11:05, David Dunham wrote:
> I've got a Cocoa app that manually creates an NSWindow (it's an
> easier fit for a cross-platform engine). From my debugging, it
> appears that every time I click another app's window, the retain
> count on my NSWindow goes up by 2 (I have a windowDidResignKey
> delegate which prints the retain count). I don't make an
> NSWindowController.
>
> If I override -[NSApplication windows] and return an empty array,
> the regain count doesn't keep climbing. This seems kind of odd.
I tried making the window in a .nib, and get the same results. The
windows retainCount keeps increasing. (Only time it doesn't is when
the window loses key due to clicking on the Dock.)
David Dunham
Voice/Fax: 206 783 7404 http://www.pensee.com/dunham/
Imagination is more important than knowledge. -- Albert Einstein -
On Feb 5, 2008, at 11:05 AM, David Dunham wrote:
> I've got a Cocoa app that manually creates an NSWindow (it's an
> easier fit for a cross-platform engine). From my debugging, it
> appears that every time I click another app's window, the retain
> count on my NSWindow goes up by 2 (I have a windowDidResignKey
> delegate which prints the retain count). I don't make an
> NSWindowController.
High retain counts are not necessarily a problem. Sometimes the
frameworks may do things like that for reasons that are not obvious on
the surface.
Are you actually seeing memory leaks after your window has been closed
and you have released it? If so, then you may want to file a bug.
- Scott -
On Feb 5, 2008, at 11:05 AM, David Dunham wrote:
> I've got a Cocoa app that manually creates an NSWindow (it's an
> easier fit for a cross-platform engine). From my debugging, it
> appears that every time I click another app's window, the retain
> count on my NSWindow goes up by 2 (I have a windowDidResignKey
> delegate which prints the retain count). I don't make an
> NSWindowController.
>
> If I override -[NSApplication windows] and return an empty array,
> the regain count doesn't keep climbing. This seems kind of odd.
>
> The behavior is happening on 10.4.11 and 10.5.1.
>
> I suspect I must be doing something wrong, but can't figure out what.
I suspect that you started to peek at the retain count of this window
for some specific reason? Why?
Like Scott suggests, tracking retain count is typically not an
effective way to troubleshoot memory management problems.
On Leopard you can use the Object Allocations instrument in
Instruments to track down where it is retained (On Tiger you can do
the same thing with the ObjectAlloc standalone app).
j o a r -
On 5 Feb 2008, at 14:04, Scott Stevenson wrote:
>> From my debugging, it appears that every time I click another app's
>> window, the retain count on my NSWindow goes up by 2 (I have a
>> windowDidResignKey delegate which prints the retain count). I don't
>> make an NSWindowController.
>
> High retain counts are not necessarily a problem. Sometimes the
> frameworks may do things like that for reasons that are not obvious
> on the surface.
True. Though continually increasing reference counts are almost always
bad.
> Are you actually seeing memory leaks after your window has been
> closed and you have released it? If so, then you may want to file a
> bug.
Yes, though it's a little difficult to isolate into a bug report.
I'm ending up solving the overall problem a slightly different way, so
I probably never will get to the bottom of this...
David Dunham
Voice/Fax: 206 783 7404 http://www.pensee.com/dunham/
Imagination is more important than knowledge. -- Albert Einstein -
On Feb 5, 2008 7:57 PM, David Dunham <dunham...> wrote:
> On 5 Feb 2008, at 14:04, Scott Stevenson wrote:
>
>>> From my debugging, it appears that every time I click another app's
>>> window, the retain count on my NSWindow goes up by 2 (I have a
>>> windowDidResignKey delegate which prints the retain count). I don't
>>> make an NSWindowController.
>>
>> High retain counts are not necessarily a problem. Sometimes the
>> frameworks may do things like that for reasons that are not obvious
>> on the surface.
>
> True. Though continually increasing reference counts are almost always
> bad.
>
>> Are you actually seeing memory leaks after your window has been
>> closed and you have released it? If so, then you may want to file a
>> bug.
>
>
> Yes, though it's a little difficult to isolate into a bug report.
>
> I'm ending up solving the overall problem a slightly different way, so
> I probably never will get to the bottom of this...
One thing you could do to track this down:
1) Create a subclass of NSWindow and override -retain and -release:
@interface MyWindow : NSWindow
@end
@implementation MyWindow
-(id)retain { return [super retain]; }
-(void)release { [super release];
@end
2) Debug your program.
3) In gdb, execute the following commands:
b -[MyWindow retain]
commands
bt 10
cont
end
b -[MyWindow release]
commands
bt 10
cont
end
This will print a lot (potentially *quite* a lot) of stack traces,
each of which is a call to retain or release.
4) Scan through the list of stacktraces and look for ones that don't
match up (i.e. find the retains that don't have a corresponding
release). There's a good chance that these unbalanced retains are in
your code somewhere.
--
Clark S. Cox III
<clarkcox3...> -
On 5 Feb 2008, at 21:27, Clark Cox wrote:
> 3) In gdb, execute the following commands:
>
> b -[MyWindow retain]
> commands
> bt 10
> cont
> end
That's the part I should learn...
> 4) Scan through the list of stacktraces and look for ones that don't
> match up (i.e. find the retains that don't have a corresponding
> release). There's a good chance that these unbalanced retains are in
> your code somewhere.
What I actually did was use OmniObjectMeter, which (at least under
Tiger) does much the same. And the unbalanced retains didn't seem to
be in my code anywhere. I couldn't really figure out where they were,
other than that (by count) it pointed to -[NSApplication windows]. And
overriding that method could get rid of the climbing retain count.
David Dunham
Voice/Fax: 206 783 7404 http://www.pensee.com/dunham/
Imagination is more important than knowledge. -- Albert Einstein -
On Feb 5, 2008, at 7:57 PM, David Dunham wrote:
>> High retain counts are not necessarily a problem. Sometimes the
>> frameworks may do things like that for reasons that are not obvious
>> on the surface.
>
> True. Though continually increasing reference counts are almost
> always bad.
That's usually true for application code, but the frameworks have a
different set of priorities to manage, so all bets are off.
For what it's worth, it's still not clear to me from this thread of
you're actually seeing leaks after the window is closed and you have
released it, or if the retain counts just seem high.
- Scott
