On Oct 16, 2013, at 3:39 PM, Charles Srstka wrote:
> 3. (This is the one I'd recommend) Instead of using NSNib, make a subclass of
> NSWindowController (if your nib defines a window) or NSViewController (if
> your nib defines a view). Then use either -[NSWindowController
> initWithWindowNibNam
On Oct 16, 2013, at 16:39:04, Charles Srstka wrote:
> Aha, that definitely explains the leaks you've been getting. The trouble with
> instantiateWithOwner:, and the reason it's been deprecated, is because it
> doesn't follow the standard Cocoa memory management rules. Specifically, it
> retain
On Oct 16, 2013, at 4:20 PM, Steve Mills wrote:
> On Oct 16, 2013, at 12:56:00, Andy Lee wrote:
>
>> As for the creeping memory footprint, maybe try Heapshot Analysis to see
>> what objects are being created during particular intervals?
>
> Aha! Thanks, I didn't know about this very helpful
On Oct 16, 2013, at 12:56:00, Andy Lee wrote:
> As for the creeping memory footprint, maybe try Heapshot Analysis to see what
> objects are being created during particular intervals?
Aha! Thanks, I didn't know about this very helpful debugging aid yet. I was
getting about a meg worth of junk e
Hi,
Out of interest, have you tried doing this:
- (NSMenuItem*)itemWithTag:(NSInteger)tag searchSubmenus:(BOOL)searchSubmenus
depthFirst:(BOOL)depthFirst
{
NSMenuItem* item; //*
NSArray*myArray;//*
NSMenuItem* subi
On 16 Oct 2013, at 18:57, Steve Mills wrote:
> So at this point, let's finish this thread by going back to my original
> question. Is it OK to use the private instance variable _itemArray in NSMenu
> since the methods we've added are *extensions* of NSMenu and not a subclass?
> They simply iter
On Oct 16, 2013, at 2:09 PM, Steve Mills wrote:
> On Oct 16, 2013, at 12:45:49, Andy Lee wrote:
>
>> I still don't see what mutability has to do with it, but that's a side issue.
>
> The mutability doesn't matter. I'm just emphasizing that the internal array
> is mutable and this is returnin
On 16 Oct 2013, at 11:57 AM, Steve Mills wrote:
> So at this point, let's finish this thread by going back to my original
> question. Is it OK to use the private instance variable _itemArray in NSMenu
> since the methods we've added are *extensions* of NSMenu and not a subclass?
> They simply
On Oct 16, 2013, at 12:45:49, Andy Lee wrote:
> I still don't see what mutability has to do with it, but that's a side issue.
The mutability doesn't matter. I'm just emphasizing that the internal array is
mutable and this is returning a COPY of that array (which happens to be
immutable).
> I
On Oct 16, 2013, at 1:38 PM, Charles Srstka wrote:
> On Oct 16, 2013, at 11:57 AM, Steve Mills wrote:
>
>> So at this point, let's finish this thread by going back to my original
>> question. Is it OK to use the private instance variable _itemArray in NSMenu
>> since the methods we've added ar
On Wed, 16 Oct 2013 01:18:18 -0700, Greg Parker said:
>You can call +[NSAutoreleasePool showPools] from the debugger to log the
>autorelease pool stack to the console (check both the debugger console
On Wed, 16 Oct 2013 01:25:45 -0700, Greg Parker said:
>those OS versions you can run with enviro
On Oct 16, 2013, at 12:57 PM, Steve Mills wrote:
> So at this point, let's finish this thread by going back to my original
> question. Is it OK to use the private instance variable _itemArray in NSMenu
> since the methods we've added are *extensions* of NSMenu and not a subclass?
> They simply
On Oct 16, 2013, at 11:57 AM, Steve Mills wrote:
> So at this point, let's finish this thread by going back to my original
> question. Is it OK to use the private instance variable _itemArray in NSMenu
> since the methods we've added are *extensions* of NSMenu and not a subclass?
I wouldn't. I
On Oct 16, 2013, at 10:08:03, Ken Thomases wrote:
> Released to the point of being deallocated? Deallocation would also be
> indicated in the history.
# Address CategoryEvent Type RefCt Timestamp Size
Responsible Library Responsible Caller
0 0x7eb9c160
On Oct 16, 2013, at 9:38 AM, Steve Mills wrote:
> On Oct 16, 2013, at 00:28:17, Ken Thomases wrote:
>
>> Regarding the general issue of the mystery objects that are still alive,
>> there's little point in speculating. Look at the object's history in the
>> Allocations instrument to see not on
On Oct 16, 2013, at 00:28:17, Ken Thomases wrote:
> Regarding the general issue of the mystery objects that are still alive,
> there's little point in speculating. Look at the object's history in the
> Allocations instrument to see not only where it was allocated but all
> retains, releases,
On Oct 16, 2013, at 03:25:45, Greg Parker wrote:
> On sufficiently-recent OS versions, the runtime will silently push an
> autorelease pool if you autorelease without one. This can lead to
> unrecognized leaks if this happens on a long-lived thread. On some of those
> OS versions you can run w
On Oct 16, 2013, at 02:31:16, Charles Srstka wrote:
> Just out of curiosity, what kind of run loop are you running in? I ask
> because the older Finale 2012 appears to use a Carbon run loop while using
> some Cocoa elements here and there. Is this still the case, or have you
> switched to a Co
On Oct 15, 2013, at 23:54:56, Jens Alfke wrote:
> Then they’re not strictly speaking leaks — something is still pointing to
> them (and likely holding references to them.)
>
> It might be an autorelease pool that isn’t getting drained, but the stack you
> showed is inside a call to -[NSMenu up
On Oct 16, 2013, at 12:31 AM, Charles Srstka wrote:
> I ask because if you're not using NSApplication's run loop, you won't get an
> automatic release pool, which would explain what you were seeing.
On sufficiently-recent OS versions, the runtime will silently push an
autorelease pool if you a
On Oct 15, 2013, at 9:13 PM, Steve Mills wrote:
> Here's a typical stack for most of the calls to itemArray:
>
> 0 libsystem_c.dylib calloc
> 1 libobjc.A.dylib _class_createInstanceFromZone
> 2 libobjc.A.dylib _class_createInstance
> 3 CoreFoundation __CFAllocateObject2
> 4 CoreFoundati
On Oct 15, 2013, at 11:13 PM, Steve Mills wrote:
> On Oct 15, 2013, at 17:22:26, Graham Cox
> wrote:
>
>> OK, so if that's the case, I'm interested in knowing whether each call to
>> -itemArray returns the same object or a different one each time. If it's
>> different, then it's either a copy
On Oct 15, 2013, at 11:54 PM, Jens Alfke wrote:
> Is it possible your code has called [NSAutoreleasePool new] someplace but not
> called -release on it when it’s done? That would have exactly this kind of
> effect — every autoreleased object would be stuck in memory but not shown as
> a leak.
On Oct 15, 2013, at 9:13 PM, Steve Mills wrote:
> This is running our release target. Zombies is off. Am I just not reading
> this data correctly? These do NOT appear as leaks in the Leaks instrument,
> only as allocations in the Allocations instrument. If I run this particular
> code over an
On Oct 15, 2013, at 17:22:26, Graham Cox
wrote:
> OK, so if that's the case, I'm interested in knowing whether each call to
> -itemArray returns the same object or a different one each time. If it's
> different, then it's either a copy of some internal array or something built
> on the fly.
On Oct 15, 2013, at 9:08 PM, Steve Mills wrote:
> I haven't retained or released anything. I'm simply calling itemArray.
What items are in the menu? How did they get there?
--
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice
_
On Oct 15, 2013, at 20:23:22, Scott Ribe
wrote:
> On Oct 15, 2013, at 4:10 PM, "Mills, Steve" wrote:
>
>> No, it's the itemArray. Ignore the code you can't see in the loop. It's
>> simply asking each item for its tag.
>
> But you could have over-retained them or under-released them somewhere
On Oct 15, 2013, at 4:10 PM, "Mills, Steve" wrote:
> No, it's the itemArray. Ignore the code you can't see in the loop. It's
> simply asking each item for its tag.
But you could have over-retained them or under-released them somewhere else,
and I think that was Graham's point.
--
Scott Ribe
On Oct 15, 2013, at 6:22 PM, Graham Cox wrote:
>
> On 15/10/2013, at 11:10 PM, "Mills, Steve" wrote:
>
>> No, it's the itemArray. Ignore the code you can't see in the loop. It's
>> simply asking each item for its tag.
>
>
> OK, so if that's the case, I'm interested in knowing whether each
On Oct 15, 2013, at 2:39 PM, Steve Mills wrote:
> I don't think this is the case. I was seeing hundreds of still-alive
> allocated objects that came from the copied itemArray. I could clearly see a
> pattern in the Allocations sampling of Instruments of these objects, with the
> pattern repeati
On 10/15/2013 2:39 PM, "Steve Mills" wrote:
>I don't think this is the case. I was seeing hundreds of still-alive
>allocated objects that came from the copied itemArray.
Ah, so within Instruments, are you looking at the objects that are
allocated or the objects that are leaking? Those are two
On 15/10/2013, at 11:10 PM, "Mills, Steve" wrote:
> No, it's the itemArray. Ignore the code you can't see in the loop. It's
> simply asking each item for its tag.
OK, so if that's the case, I'm interested in knowing whether each call to
-itemArray returns the same object or a different one e
On Oct 15, 2013, at 17:05, "Graham Cox"
mailto:graham@bigpond.com>> wrote:
On 15/10/2013, at 10:39 PM, Steve Mills
mailto:smi...@makemusic.com>> wrote:
I was seeing hundreds of still-alive allocated objects that came from the
copied itemArray
OK, so the objects *IN* the array are leaking
On 15/10/2013, at 10:39 PM, Steve Mills wrote:
> I was seeing hundreds of still-alive allocated objects that came from the
> copied itemArray
OK, so the objects *IN* the array are leaking, not the array itself, as you
initially stated?
That's a totally different, probably unrelated issue. Pr
On Oct 15, 2013, at 16:05:06, Andy Lee wrote:
> Out of curiosity, when you say you have "extended" NSMenu, do you mean you've
> subclassed it? That is what I would infer from your mention of class
> extensions. Is there some reason you don't add a category instead? I wonder
> because you on
On Oct 15, 2013, at 15:35:32, Kyle Sluder
wrote:
> They shouldn't be leaking. You're correct that -itemArray doesn't follow
> the naming convention of an object-creation method (new, alloc, copy,
> etc.), so you should not assume a +1 owning reference.
Thanks for confirming that.
> Are you per
On Oct 15, 2013, at 4:30 PM, Steve Mills wrote:
> On Oct 15, 2013, at 14:50:51, Steve Mills wrote:
>
>> NSArray*items = [self itemArray];
>>
>> for(NSMenuItem* item in items)
>> blah;
>>
>> [items release];
>
>
> Ah, this one won't work (
On Oct 15, 2013, at 5:05 PM, Andy Lee wrote:
> Then instead of [self itemArray] you could use [self nonLeakingItemArray].
If you are indeed subclassing, even better would be to override itemArray to
return [self nonLeakingItemArray]. Then you can use [self itemArray]
everywhere else and the co
On Oct 15, 2013, at 3:50 PM, Steve Mills wrote:
> We have extended NSMenu so we could add some other methods. Many of the
> methods iterate over the itemArray like so:
>
> for(NSMenuItem* item in [self itemArray])
>
> Instruments shows that we're leaking NSArrays created when itemArray re
On Tue, Oct 15, 2013, at 12:50 PM, Steve Mills wrote:
> We have extended NSMenu so we could add some other methods. Many of the
> methods iterate over the itemArray like so:
>
> for(NSMenuItem* item in [self itemArray])
>
> Instruments shows that we're leaking NSArrays created when itemArra
On Oct 15, 2013, at 12:50 PM, Steve Mills wrote:
> Instruments shows that we're leaking NSArrays created when itemArray returns.
> I assume whoever wrote these methods was assuming that itemArray would simply
> return the internal NSArray and not make a copy.
You don’t need to release the ret
On Oct 15, 2013, at 14:50:51, Steve Mills wrote:
> NSArray*items = [self itemArray];
>
> for(NSMenuItem* item in items)
> blah;
>
> [items release];
Ah, this one won't work (I didn't try it before when I wrote my original
message) b
42 matches
Mail list logo
