Also turn on Zombie Objects and the other diagnostic features in Xcode edit
Scheme -> Diagnostics.
-Owen
> On Aug 26, 2019, at 1:43 PM, Jean-Daniel via Cocoa-dev
> <cocoa-dev@lists.apple.com> wrote:
>
> A better way to investigate such issue is using the memory debugging tools in
> Instrument IMHO.
> That would let you see all stack traces of retain/release calls.
>
>> Le 26 août 2019 à 04:14, Turtle Creek Software via Cocoa-dev
>> <cocoa-dev@lists.apple.com> a écrit :
>>
>> In GSAppDelegate.h
>> GSOutlineWindowController *mainWindowController;
>>
>> In GSAppDelegate.mm
>> - (void) showOutlineWindow
>> {
>> if (mainWindowController == NULL)
>> mainWindowController = [[GSOutlineWindowController alloc]
>> initWithWindowNibName : @"GSOutlineWindowController"];
>> [mainWindowController showWindow : self];
>> }
>>
>> We don't do any ref-counting at all. A search for CFRetain and CFRelease
>> showed zero items.
>>
>> I would say that ARC is certainly way better than the previous manual
>> ref-counting. That must have been hellish.
>> Fortunately we only started the Carbon->Cocoa port 3 years ago, so we
>> didn't need to retain/release.
>> But we have wasted at least a month, tracking down mysterious object
>> deletions that theoretically should not happen.
>>
>> At this point we pretty much have breakpoints on dealloc() for every
>> class. That lets us know when something is
>> dying, but gives no clue as to why. Breakpoints on release() go deep into
>> Apple Assembly code.
>>
>> On Sun, Aug 25, 2019 at 12:42 PM Jens Alfke <j...@mooseyard.com> wrote:
>>
>>>
>>>> On Aug 24, 2019, at 4:46 AM, Turtle Creek Software <
>>> supp...@turtlesoft.com> wrote:
>>>>
>>>> Our app delegate class is not deallocated. The window controller is
>>> deallocated
>>>> despite the member reference there.
>>>
>>> That should not be possible. Could you paste the exact line of code that
>>> declares the window-controller reference in the app delegate?
>>>
>>> Have you verified that, at the point when the controller is dealloced, the
>>> reference in the app delegate is still non-nil? (I sometimes find it useful
>>> to set a breakpoint in the dealloc method, in weird cases like this.)
>>>
>>> Do you have any remaining code that messes with ref-counting, I.e. by
>>> using CFRetain/Release on Obj-C objects?
>>>
>>> —Jens
>>>
>>> (And let me chime in that ARC is an excellent feature. Cocoa used to have
>>> ‘true’ garbage collection as an option, but it was rarely used on Mac due
>>> to memory and performance impact, and never implemented on iOS for that
>>> reason. ARC works much better. Swift memory management is based on ARC, so
>>> it’s definitely the way of the future.)
>>>
>> _______________________________________________
>>
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>>
>> 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:
>> https://lists.apple.com/mailman/options/cocoa-dev/mailing%40xenonium.com
>>
>> This email sent to mail...@xenonium.com
>
> _______________________________________________
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
> 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:
> https://lists.apple.com/mailman/options/cocoa-dev/owen%40clipboardinc.com
>
> This email sent to o...@clipboardinc.com
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
