Re: Debugging a CALayer Bad Access
Re: Debugging a CALayer Bad Access
- Subject: Re: Debugging a CALayer Bad Access
- From: Gordon Apple <email@hidden>
- Date: Sat, 01 Jun 2013 13:19:22 -0500
- Thread-topic: Debugging a CALayer Bad Access
Title: Re: Debugging a CALayer Bad Access
Sorry for the delay. I’ve been digesting your comments and trying to get more familiar with Instruments. I’m mainly closing windows via “close” in the window controller. I did get a little over zealous on the weak outlets. Outlets to UI elements should probably always be weak, but outlets from the nib owner to top-level elements should mostly be strong. NSNib allows you to get a list of top-level elements, which can be retained individually or by the returned array, but window controllers don’t give you that, so you have to make them explicit.
Because I typically split my controllers (included in the nib), according to function, I don’t often use “awakeFromNib” due to unredictability of order. Instead, I use my own “wakeUp” routine (called from the window controller) so I can guarantee the order. There may be a similar issue in dealloc.
On 5/30/13 2:39 PM, "Fritz Anderson" <email@hidden> wrote:
Jens's advice is good in all cases, but I want to comment on how to pursue your particular issue (assuming I understand it correctly).
On 30 May 2013, at 12:40 PM, Gordon Apple <email@hidden> wrote:
> Debugging is not my strong suit. I usually rely on console messages, stack trace, logic, isolation, trial and error.
(Not using the debugger _at all?_)
Make it your strong suit. Most of your techniques are perfectly valid, and easier to do with a debugger, but the generally accepted term for "trial and error" is "blind thrashing." I have no confidence that shotgunning weak pointers at your memory management will give you a robust solution.
> I have several types (nibs) of document windows, only one of which can be used at a time. Switching involves closing one and opening another. After realizing that the closed windows were not deallocating
How are you closing them? If it's by -orderOut:, failing to release is the expected behavior.
If it's by -close or -performClose:, the expected behavior is _usually_ to release the window, but sometimes not. Read the documentation for -close (both NSWindowController and NSWindow), -performClose:, -orderOut:, -isReleasedWhenClosed, and -setReleasedWhenClosed:. Also, Xcode's XIB templates sometimes set Release When Closed (checkbox in the window's attributes inspector), sometimes not, thus overriding the default behavior. Audit your XIBs.
Note that if the window NIB is loaded by an NSWindowController, Released When Closed is ignored; deallocating the controller deallocates the window. Search the documentation for "Managing Nib Objects in OS X".
> After realizing that the closed windows were not deallocating, I made sure all my iBOutlets were weak.
All your IBOutlets to what? From what? _Some_ references could be weak if you'd like them to be. I guess it's possible that throwing "weak" at _all_ your references would do no harm, but I don't think it's the way to bet. AppKit is supposed to do the right thing without extraordinary workarounds. Research and analyze first; work from principles. If you have 10 outlets, you'd have to try-and-err 512 times on the average. (If you're not lucky, you'll hit on an _apparent_ solution early, only to crash, perhaps more subtly, in the future.)
> The bad news is that they crash with “bad access” and no console messages.
The debugger would give you better console messages, even if you're not interested in tools that provide more and better information than console messages.
And as Jens said, debug (set Enable Zombie Objects in the Diagnostics tab of the Run action in the Scheme editor) or profile (one of the options in the Allocations instrument) using zombie detection.
— F
--
Gordon Apple
Ed4U
Little Rock, AR
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden