• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Lingering windows
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Lingering windows


  • Subject: Re: Lingering windows
  • From: Shane Stanley <email@hidden>
  • Date: Wed, 10 Aug 2011 15:34:10 +1000

On Aug 10, 2011, at 3:12 PM, Quincey Morris wrote:

> Starting at the bottom, the last 3 show strong references to the window from object 0x0000000400efa2e0. *That* object is being kept alive by 2 stack references (#6 and #7), but it's a root reference in itself. I wouldn't be surprised if this is the window controller.
>
> You don't happen to have a singleton pattern of some kind for the window's window controller? I mean something like [MyWindowController sharedWindowController]. The simplest implementation of that pattern doesn't ever release the singleton.

In my document class's -makeWindowControllers I'm setting a property to the window controller; could that be the problem?

(I'm only subclassing the window to override validateUserInterfaceItem: to stop performClose: at certain times.)
>
> The first 4 roots are all stack references directly to the window.

Yep, I realise now they're related to code I put in to get the address.
>
> The next step is to try getting the debugger to tell you the class of the referencing objects -- 'po [0x0000000400efa2e0 class]', etc.
>
> Note that the only root that *isn't* a stack variable is #5, so that's the one I would be suspicious of. (After all, at a certain point, you'd expect all the stack frames that might have a variable referring to a window to be popped by the time you get back to the main event loop, so stack references shouldn't really be what's keeping this alive, unless a reference to the window has migrated up to a stack frame above the main event loop.)
>
> If you get nowhere useful with the debugger, you can try following up in Instruments (Allocations and Leaks). If a window gets leaked for every document you open (but isn't detected by Instruments as a leak), then the quickest way to get a picture of what's going on is to use heapshot analysis:
>
> 	http://www.friday.com/bbum/2010/10/17/when-is-a-leak-not-a-leak-using-heapshot-analysis-to-find-undesirable-memory-growth/

Thanks for the further ideas. I think ;-)

--
Shane Stanley <email@hidden>
'AppleScriptObjC Explored' <www.macosxautomation.com/applescript/apps/>

_______________________________________________

Cocoa-dev mailing list (email@hidden)

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:

This email sent to email@hidden

  • Follow-Ups:
    • Re: Lingering windows
      • From: Quincey Morris <email@hidden>
References: 
 >Lingering windows (From: Shane Stanley <email@hidden>)
 >Re: Lingering windows (From: Quincey Morris <email@hidden>)
 >Re: Lingering windows (From: Shane Stanley <email@hidden>)
 >Re: Lingering windows (From: Quincey Morris <email@hidden>)

  • Prev by Date: Re: Menu Item Key Equivalent
  • Next by Date: Re: CFMutableDictionary Capacity
  • Previous by thread: Re: Lingering windows
  • Next by thread: Re: Lingering windows
  • Index(es):
    • Date
    • Thread