Re: Debugging a CALayer Bad Access
Re: Debugging a CALayer Bad Access
- Subject: Re: Debugging a CALayer Bad Access
- From: Fritz Anderson <email@hidden>
- Date: Thu, 30 May 2013 14:39:53 -0500
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
--
Fritz Anderson
Xcode 4 Unleashed: 4.5 supplement for free!
http://www.informit.com/store/xcode-4-unleashed-9780672333279
_______________________________________________
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