Turning off ARC in one file helped track down the problem. Thanks Daniel!
With breakpoints in retain and autorelease, it was possible to step through
the whole tab setup process. Turns out that NSTabViewController's
addChildViewController calls didSelectTabViewItem before the tab is set up
In the Build Phases tab of the target, open compile sources and set the
compiler flags for your subclass’s .m to -fno-objc-arc.
Don’t forget that the signature for -release is -(oneway void)release, not just
-(void)release :)
Daniel
> On May 22, 2019, at 12:13 PM, Carl Hoefs
> wrote:
>
>
On 5/22/19 11:20 AM, Casey McDermott wrote:
Instruments shows the child view controller being deallocated improperly
after a tab switch.
Unfortunately it's either run the debugger or run Instruments, but not both.
So it doesn't help narrow down to when the release happens, exactly.
> On May 22, 2019, at 11:31 AM, Daniel DeCovnick wrote:
>
> You can always subclass, turn off ARC for that file, and override -release or
> -autorelease to breakpoint in.
How does one turn off ARC for a specific file?
-Carl
___
Cocoa-dev mailing
With current ARC, it's not allowed to override retain, release, autorelease or
retaincount.
Too bad, because breakpoints there can really help when debugging lifetime
issues.
Worst case, I guess we could go back to an earlier Xcode that allows them.
But that won't be fun.
Casey McDermott
You can always subclass, turn off ARC for that file, and override -release or
-autorelease to breakpoint in. I’ve done that on occasion with particularly
tricky overrelease bugs (which actually turned out to be an under-autorelease
bug in some non-ARC code).
Daniel
> On May 22, 2019, at 11:20
Instruments shows the child view controller being deallocated improperly after
a tab switch.
Unfortunately it's either run the debugger or run Instruments, but not both.
So it doesn't help narrow down to when the release happens, exactly.
Instruments has an Allocations list that shows caller
In the past, if the crash like that was reliably and not to complicated to recreate and I
had no other choice, then overriding -autorelease and putting a breakpoint into that
worked on some occasions. Be prepared to get a lot of hits though.
The object likely gets over-released by an
> On May 22, 2019, at 1:19 PM, Casey McDermott wrote:
>
> The Allocations feature in Instruments looks promising. Is there a way to
> limit the display to just one class? Otherwise it is WTMI.
Check out File → Recording Options…
Matt
___
Yes, we added a NSArray in the tab view controller with a strong ref to each
child view controller. That slows down the crash by one cycle,
but doesn't provide any additional clues.
Is there a way for NSZombie to show when the object is released? AFAICT it only
kicks in on dealloc. We can see
When you say "separate, strong reference to each tab view controller” do you
mean each child view controller that controls a single tab view item, or the
tab view controller as a whole? It is keeping string references to the
individual child view controllers that should solve your situation.
On 5/22/19 7:26 AM, Casey McDermott wrote:
Our Mac app adds tabs to a NSTabView programmatically. After switching tabs a
few times, one of the NSTabViewItems would release
prematurely, causing a crash. So we switched it to using a
NSTabViewController. Tab switching still crashes, but now it
Our Mac app adds tabs to a NSTabView programmatically. After switching tabs a
few times, one of the NSTabViewItems would release
prematurely, causing a crash. So we switched it to using a
NSTabViewController. Tab switching still crashes, but now it releases a
NSViewController prematurely.
13 matches
Mail list logo
