Re: ARC problems
>> Is that view controller voiding its own self reference? No. >> Is it possible to switch out the view controller that i disappearing with another one and see if that also disappears? We've already wasted 2 weeks trying to debug this. It's time to move on. We won't finish in time for Catalina, but maybe we can finish in time for Apple to switch to ARM chips and require another big rewrite ;-< Casey McDermott TurtleSoft.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
Re: ARC problems
On 4 Sep 2019, at 0:18, Turtle Creek Software via Cocoa-dev wrote: The startup code was created 3 years ago when we were new to Cocoa, probably from one of the HIllegass books. Do you manually load nibs (as opposed to rely on the framework to load MainMenu.nib)? In a previous post you wrote: Our app delegate class is not deallocated. The window controller is deallocated despite the member reference there. If we keep the second strong reference to the controller, then the outline view is deallocated instead. Nothing references the view except being in the .xib file for the window controller. We had similar problems with a NSTabViewer. When we futzed the build settings to allow To me it sounds like your nib is not being retained. This one contains the app delegate as a top-level object, so this gets released unless something else retains it (like when you had the main window controller retain the app delegate with a strong back-reference, but then you saw views being released instead). So you need to look at the setup code, if it is using modern NSNib loading methods, it will need to keep the array of top-level objects (and the nib itself) retained for the duration of the program. The nib is (it sounds) the root of your ownership hierarchy, and you are retaining objects further down the tree, which doesn’t correctly fix the problem. ___ 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
Re: ARC problems
> Le 4 sept. 2019 à 00:18, Turtle Creek Software a > écrit : > > The app delegate is NOT being deallocated prematurely- we have a breakpoint > there to check. > > We don't allocate the app delegate explicitly, so I had to set a breakpoint > in init() to see when it happens. > It's created in main() via NSApplicationMain. Presumably its end of scope > would be when main ends. > The MainMenu.xib includes a Delegate object for our GSAppDelegate class, so > it must be allocated > via the nib-loading process (the stack trace says InitWithCoder). > > GSAppDelegate has strong references to 4 window controller members: main > window, prefs window, and a couple of log windows. > But that alone has not kept the main window controller alive. We haven't > tested the others. > > The main window controller that was mysteriously dying used to have a strong > reference back to the app delegate. > Whether strong, weak or non-existent, it didn't make any difference. I > suppose we could add a strong ref somewhere else > just to be double safe, but I'm not sure where else would make sense. You can get the same effect by retaining the controller explicitly (creating a leak, so should be for testing purpose only). CFBridgingRetain(windowController); > The startup code was created 3 years ago when we were new to Cocoa, probably > from one of the HIllegass books. > It may have flaws, but the app has been running OK otherwise. The problems > only started when we read about circular references > and started making up-references __weak. > > BTW the Clang specs for ARC mention that it's not exception-safe. If I > understand correctly, > strong references will leak, and weak references are released. We don't > throw any Cocoa exceptions but > maybe the system does. Manual Ref counting was not safe either, just like almost everything in Obj-C frameworks. Exception are used only for fatal errors (expect in a couple of legacy API). Don’t bother with exception safety. If your code raises an exception, fix the bug to avoid seeing it again. ___ 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
Re: ARC problems
Is it possible to switch out the view controller that i disappearing with another one and see if that also disappears? Is that view controller voiding its own self reference? > On Sep 3, 2019, at 5:18 PM, Turtle Creek Software via Cocoa-dev > wrote: > > The app delegate is NOT being deallocated prematurely- we have a breakpoint > there to check. > > We don't allocate the app delegate explicitly, so I had to set a breakpoint > in init() to see when it happens. > It's created in main() via NSApplicationMain. Presumably its end of scope > would be when main ends. > The MainMenu.xib includes a Delegate object for our GSAppDelegate class, so > it must be allocated > via the nib-loading process (the stack trace says InitWithCoder). > > GSAppDelegate has strong references to 4 window controller members: main > window, prefs window, and a couple of log windows. > But that alone has not kept the main window controller alive. We haven't > tested the others. > > The main window controller that was mysteriously dying used to have a > strong reference back to the app delegate. > Whether strong, weak or non-existent, it didn't make any difference. I > suppose we could add a strong ref somewhere else > just to be double safe, but I'm not sure where else would make sense. > > The startup code was created 3 years ago when we were new to Cocoa, > probably from one of the HIllegass books. > It may have flaws, but the app has been running OK otherwise. The problems > only started when we read about circular references > and started making up-references __weak. > > BTW the Clang specs for ARC mention that it's not exception-safe. If I > understand correctly, > strong references will leak, and weak references are released. We don't > throw any Cocoa exceptions but > maybe the system does. > > Casey McDermott > > On Tue, Sep 3, 2019 at 4:24 PM Jean-Daniel wrote: > >> >>> Le 3 sept. 2019 à 02:33, Turtle Creek Software via Cocoa-dev < >> cocoa-dev@lists.apple.com> a écrit : >>> >>> Thanks for all the suggestions for the problems we had with a controller >>> being >>> deallocated unexpectedly under ARC. Unfortunately, none of them fixed >> it. >>> >>> We do need to get back to regular app programming, so it will just stay a >>> mystery. >>> I was hoping we were doing something obviously dumb, but I guess the bug >> is >>> more subtle. >>> >>> The app runs OK with the old code with multiple strong references to it >>> They are circular references, but that controller sticks around for the >>> full app lifetime. Presumably any leakage >>> won't happen until late in the game, anyhow. >>> >>> Thanks, >> >> Just a last suggestion. How is you App delegate created ? Do you keep a >> strong ref on it. Else it will be deallocated and so will the controller. >> >> > ___ > > 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/zav%40mac.com > > This email sent to z...@mac.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
Re: ARC problems
The app delegate is NOT being deallocated prematurely- we have a breakpoint there to check. We don't allocate the app delegate explicitly, so I had to set a breakpoint in init() to see when it happens. It's created in main() via NSApplicationMain. Presumably its end of scope would be when main ends. The MainMenu.xib includes a Delegate object for our GSAppDelegate class, so it must be allocated via the nib-loading process (the stack trace says InitWithCoder). GSAppDelegate has strong references to 4 window controller members: main window, prefs window, and a couple of log windows. But that alone has not kept the main window controller alive. We haven't tested the others. The main window controller that was mysteriously dying used to have a strong reference back to the app delegate. Whether strong, weak or non-existent, it didn't make any difference. I suppose we could add a strong ref somewhere else just to be double safe, but I'm not sure where else would make sense. The startup code was created 3 years ago when we were new to Cocoa, probably from one of the HIllegass books. It may have flaws, but the app has been running OK otherwise. The problems only started when we read about circular references and started making up-references __weak. BTW the Clang specs for ARC mention that it's not exception-safe. If I understand correctly, strong references will leak, and weak references are released. We don't throw any Cocoa exceptions but maybe the system does. Casey McDermott On Tue, Sep 3, 2019 at 4:24 PM Jean-Daniel wrote: > > > Le 3 sept. 2019 à 02:33, Turtle Creek Software via Cocoa-dev < > cocoa-dev@lists.apple.com> a écrit : > > > > Thanks for all the suggestions for the problems we had with a controller > > being > > deallocated unexpectedly under ARC. Unfortunately, none of them fixed > it. > > > > We do need to get back to regular app programming, so it will just stay a > > mystery. > > I was hoping we were doing something obviously dumb, but I guess the bug > is > > more subtle. > > > > The app runs OK with the old code with multiple strong references to it > > They are circular references, but that controller sticks around for the > > full app lifetime. Presumably any leakage > > won't happen until late in the game, anyhow. > > > > Thanks, > > Just a last suggestion. How is you App delegate created ? Do you keep a > strong ref on it. Else it will be deallocated and so will the controller. > > ___ 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
Re: ARC problems
> Le 3 sept. 2019 à 02:33, Turtle Creek Software via Cocoa-dev > a écrit : > > Thanks for all the suggestions for the problems we had with a controller > being > deallocated unexpectedly under ARC. Unfortunately, none of them fixed it. > > We do need to get back to regular app programming, so it will just stay a > mystery. > I was hoping we were doing something obviously dumb, but I guess the bug is > more subtle. > > The app runs OK with the old code with multiple strong references to it > They are circular references, but that controller sticks around for the > full app lifetime. Presumably any leakage > won't happen until late in the game, anyhow. > > Thanks, Just a last suggestion. How is you App delegate created ? Do you keep a strong ref on it. Else it will be deallocated and so will the controller. ___ 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
ARC problems
Thanks for all the suggestions for the problems we had with a controller being deallocated unexpectedly under ARC. Unfortunately, none of them fixed it. We do need to get back to regular app programming, so it will just stay a mystery. I was hoping we were doing something obviously dumb, but I guess the bug is more subtle. The app runs OK with the old code with multiple strong references to it They are circular references, but that controller sticks around for the full app lifetime. Presumably any leakage won't happen until late in the game, anyhow. Thanks, Casey McDermott TurtleSoft.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
