Re: showing window causes EXC_BAD_ACCESS
Am Sa,27.09.2008 um 22:44 schrieb Uli Kusterer: On 27.09.2008, at 22:13, Michael Ash wrote: But suddenly you're back to having to think about the global picture of who owns objects, which is what Cocoa's memory management system is supposed to avoid. Retains and releases should be balanced. This doesn't just means that they should ultimately be equal in number, it also means that the same entity should be doing both. Release when closed breaks the fundamental memory management rules and, as a consequence, makes it much more complicated to think about how the program works. You're misunderstanding the purpose of Cocoa's memory management system: It's not about not having to care who owns what, it's about not having to worry about shared ownership. There are many cases (threading and creation of objects come to mind) where ownership is handed from one object to the other. In this case, you specify in the NIB that you want your window to release itself, and you haven't written your outlet in a way that it retains the window. If you expect your window to not go away when closed, you're expecting too much. Hallo Uli, :-) I think, that you have to keep in mind, that sometimes you have instances in a nib, which have no retain at all. Simply think of a stand-alone delegate for an UI-element. It is not retained by the UI- element (delegates are not retained to avoid retain cycles as you know). So loading a nib unfortunatly is not balanced. When you think of loading the nib-objects as instance creation, the mm-rules are broken: Usually you balance the +alloc with a -retain (some lines later, sometimes in -dealloc) or an immediate -autorelease. The nib-loader does not do that. So $somebody has to release the instances, when the nib is unloaded. So loading objects through the nib-loader is like a naked +alloc, - init*. You can see eht nib-exception of mm-rules, when you handle the top- level objects your own. You probably store them in an array, which sends a retain to the objects. The first thing you have to do, is to send a -release to all top-level objects to balance the nib-loaders +alloc. So, after all: You have to release top-level objects of the nib manually, when unloading the nib. I think, that release, when closed is simply a convenient option, because in many cases you have only a window in the nib and it is the only object, that has to be released. And usually closing a window means unloading the nib to get the free memory. So in this cases you have to do nothing in your code, if you checked that option. That said, I fully agree on one partial point you raised: 'Release when closed' is dangerous and complicates matters. Yes. Anyway you should always use a window controller or view controller to get rid of the problems with nibs and mm. It should be off by default, and it's very likely that nobody would miss it. In this case, you will get a memory leak everytime you simply do not care about the nib loading. You would always need extra release-code. Think of a simple about-window. You have an action, let's call it - showAboutWindow: and load the nib there. If the user closes this window, it is released automatically. You have to do nothing. And you do not have to take care about other instances in that nib, because there are no other instances: 0 lines of code. (In reality this is not true, because you have to take care, that the nib is not reloaded. So you have to handle the window close for that purpose and then can add a -release.) That said, I don't know what it was originally introduced for. Any old NeXTies here who know? longW told me, that there had not been window controllers prior to 10.0 to handle the mm of nib-objects. :-) view controllers are introduced with 10.5. So the whole nib-loading mechanism looks a littlebit – eh – archaeological. Cheers, Cheers, -- Uli Kusterer The Witnesses of TeachText are everywhere... http://www.zathras.de ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/negm-awad%40cocoading.de This email sent to [EMAIL PROTECTED] Amin Negm-Awad [EMAIL PROTECTED] ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: showing window causes EXC_BAD_ACCESS
Except that in every case I've seen of people getting bit by this, the window was still being implicitly retained by the nib's File's Owner. You should definitely *not* expect a top-level nib object to go away until File's Owner releases it. Sure. The design intent here is that File's Owner is being dealloc'd, so the window (along with all other top-level nib objects) should go away. -- Scott Ribe [EMAIL PROTECTED] http://www.killerbytes.com/ (303) 722-0567 voice ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: showing window causes EXC_BAD_ACCESS
On Sun, Sep 28, 2008 at 11:01 AM, Scott Ribe [EMAIL PROTECTED] wrote: Except that in every case I've seen of people getting bit by this, the window was still being implicitly retained by the nib's File's Owner. You should definitely *not* expect a top-level nib object to go away until File's Owner releases it. Sure. The design intent here is that File's Owner is being dealloc'd, so the window (along with all other top-level nib objects) should go away. Are you saying this is the design intent of release when closed? Because that makes no sense to me; the window that gets released when closed is not File's Owner, it's just a random top-level nib object whose lifetime should be managed by File's Owner and not by itself. Mike ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: showing window causes EXC_BAD_ACCESS
No. But I'm still wondering. How would you set up a reference again if you chose to have the window released on close...without reloading the entire nib, which is probably counterproductive. On Sep 26, 2008, at 3:30 PM, Charles Steinman wrote: If it's accessed via an outlet in your app controller, you probably don't have multiple instances of it floating around like Scott was talking about, do you? ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: showing window causes EXC_BAD_ACCESS
On Sat, Sep 27, 2008 at 1:06 PM, Daniel Child [EMAIL PROTECTED] wrote: No. But I'm still wondering. How would you set up a reference again if you chose to have the window released on close...without reloading the entire nib, which is probably counterproductive. Released does not mean Dealloced. --Kyle Sluder ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: showing window causes EXC_BAD_ACCESS
On 27.09.2008, at 19:06, Daniel Child wrote: No. But I'm still wondering. How would you set up a reference again if you chose to have the window released on close...without reloading the entire nib, which is probably counterproductive. Well, for some windows, you might not need another reference. Imagine you have a window of which you can open several, like the Get Info panel in some apps. Your window controller would listen for the window closed notification and commit suicide upon receiving it, and the window would go away. Though I agree that it's a better design to just not use this flag, and just have the window controller destroy itself when the window is closed, and take down the window the regular way. Also, there are cases where someone else is going to retain a window anyway. Closing a window will simply call -release, if someone else retained it, the object won't go away. Cheers, -- Uli Kusterer The Witnesses of TeachText are everywhere... http://www.zathras.de ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: showing window causes EXC_BAD_ACCESS
On Sat, Sep 27, 2008 at 2:39 PM, Uli Kusterer [EMAIL PROTECTED] wrote: Also, there are cases where someone else is going to retain a window anyway. Closing a window will simply call -release, if someone else retained it, the object won't go away. But suddenly you're back to having to think about the global picture of who owns objects, which is what Cocoa's memory management system is supposed to avoid. Retains and releases should be balanced. This doesn't just means that they should ultimately be equal in number, it also means that the same entity should be doing both. Release when closed breaks the fundamental memory management rules and, as a consequence, makes it much more complicated to think about how the program works. Mike ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: showing window causes EXC_BAD_ACCESS
On 27.09.2008, at 22:13, Michael Ash wrote: But suddenly you're back to having to think about the global picture of who owns objects, which is what Cocoa's memory management system is supposed to avoid. Retains and releases should be balanced. This doesn't just means that they should ultimately be equal in number, it also means that the same entity should be doing both. Release when closed breaks the fundamental memory management rules and, as a consequence, makes it much more complicated to think about how the program works. You're misunderstanding the purpose of Cocoa's memory management system: It's not about not having to care who owns what, it's about not having to worry about shared ownership. There are many cases (threading and creation of objects come to mind) where ownership is handed from one object to the other. In this case, you specify in the NIB that you want your window to release itself, and you haven't written your outlet in a way that it retains the window. If you expect your window to not go away when closed, you're expecting too much. That said, I fully agree on one partial point you raised: 'Release when closed' is dangerous and complicates matters. It should be off by default, and it's very likely that nobody would miss it. That said, I don't know what it was originally introduced for. Any old NeXTies here who know? Cheers, -- Uli Kusterer The Witnesses of TeachText are everywhere... http://www.zathras.de ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: showing window causes EXC_BAD_ACCESS
On Sep 27, 2008, at 4:44 PM, Uli Kusterer wrote: That said, I fully agree on one partial point you raised: 'Release when closed' is dangerous and complicates matters. It should be off by default, and it's very likely that nobody would miss it. That said, I don't know what it was originally introduced for. Any old NeXTies here who know? Well, I'm not an old NeXTie, but I use this when I make a throw away window programmatically. Something like the About panel, say. Instead of setting up a delegate and have it autorelease the window on the -windowShouldClose: method, I just set it up with release when closed and I know when the window is closed it gets released. I have no idea why it's an option in a nib file, though. Perhaps someone just wanted to be thorough in giving you the window's options? Does the window really get deallocated when using this option? I haven't really looked, but wouldn't the nib's owner still have a reference to it as part of its top level objects? -- Darkshadow (aka Michael Nickerson) http://www.nightproductions.net ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: showing window causes EXC_BAD_ACCESS
On Sat, Sep 27, 2008 at 4:44 PM, Uli Kusterer [EMAIL PROTECTED] wrote: On 27.09.2008, at 22:13, Michael Ash wrote: But suddenly you're back to having to think about the global picture of who owns objects, which is what Cocoa's memory management system is supposed to avoid. Retains and releases should be balanced. This doesn't just means that they should ultimately be equal in number, it also means that the same entity should be doing both. Release when closed breaks the fundamental memory management rules and, as a consequence, makes it much more complicated to think about how the program works. You're misunderstanding the purpose of Cocoa's memory management system: It's not about not having to care who owns what, it's about not having to worry about shared ownership. There are many cases (threading and creation of objects come to mind) where ownership is handed from one object to the other. It's just two different sides of the same coin. Why is it useful to be able to ignore shared ownership? Because it turns memory management from a global problem into a local problem. How does Cocoa make memory management a local problem? By allowing us to easily deal with shared ownership. I did not mean to imply that ownership never gets passed from one object to another. Only that when you balance a retain with a release, the entity doing the release should be the same one doing the retain. Anything other approach turns the problem back into a global one, and makes life much more difficult. In this case, you specify in the NIB that you want your window to release itself, and you haven't written your outlet in a way that it retains the window. If you expect your window to not go away when closed, you're expecting too much. Except that in every case I've seen of people getting bit by this, the window was still being implicitly retained by the nib's File's Owner. You should definitely *not* expect a top-level nib object to go away until File's Owner releases it. Mike ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: showing window causes EXC_BAD_ACCESS
I can't think of a single reasonable use case for it An app with many windows, many of which can display multiple instances at a time--they should be released when closed. I'd turn the question around--why do people assume that a single instance of a window can be closed and then re-displayed, especially when the reference to it was obviously not retained properly to begin with. -- Scott Ribe [EMAIL PROTECTED] http://www.killerbytes.com/ (303) 722-0567 voice ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: showing window causes EXC_BAD_ACCESS
On Fri, Sep 26, 2008 at 11:34 AM, Scott Ribe [EMAIL PROTECTED] wrote: I can't think of a single reasonable use case for it An app with many windows, many of which can display multiple instances at a time--they should be released when closed. Sure. By the objects that own them. Them's the rules, after all. I'd turn the question around--why do people assume that a single instance of a window can be closed and then re-displayed, especially when the reference to it was obviously not retained properly to begin with. How was it not retained properly to begin with? The window releases *itself*. Generally the nib owner will continue to own a reference to every window inside. But that won't prevent an object which breaks the rules and does a [self release] from going a way, which is exactly what happens here. People quite correctly assume that if they retain an object (whether explicitly or, in the case of being file's owner of a nib, implicitly) that this object stays alive until they release it. This NSWindow setting breaks that contract. Thus my inability to see its usefulness. As Kyle pointed out, the real problem is that this flag is enabled by default. NSWindow has more than one setting which will completely destroy its functionality in non-obvious ways, but all the other settings are given a sane default in IB. Mike ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: showing window causes EXC_BAD_ACCESS
I should? Then how do I get the reference back? If windowA is a window outlet in my AppController, then first time around I don't do anything. It is automatically assigned a reference when the window loads, and I can use makeKeyAndOrderFront. But if I choose to automatically release the window on closing, how do I get the variable windowA reassigned to the window? I don't want to reload the entire nib because there may be other things in the nib that don't need to be reloaded On Sep 26, 2008, at 1:33 PM, [EMAIL PROTECTED] wrote: Message: 1 Date: Fri, 26 Sep 2008 10:34:50 -0500 From: Scott Ribe [EMAIL PROTECTED] Subject: Re: showing window causes EXC_BAD_ACCESS To: Michael Ash [EMAIL PROTECTED], Cocoa Developers cocoa-dev@lists.apple.com Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=US-ASCII I can't think of a single reasonable use case for it An app with many windows, many of which can display multiple instances at a time--they should be released when closed. ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
showing window causes EXC_BAD_ACCESS
Hi,
I'm stumped. I have a button in a master window tied to a method that
simply shows another window. The method is as simple as they come.
- (IBAction) showMLTableListings: (id) sender
{
[mLTableListingsWindow makeKeyAndOrderFront: self];
}
where mLTableListingsWindow is simply the reference to the data
listing window cached within the App Controller.
If I press the button in question once, the window dutifully comes up.
If I close the window and press the button a second time, I get
EXC_BAD_ACCESS. Debugging, I found that both self and
mLTableListingsWindow still exist.
Incidentally, the tables and windows were set up automatically using
the entity object in IB, as I'm simply testing a CoreData app. I
didn't set any of the bindings manually. This seems to happen on a
number of my automatically generated CoreData windows?
Why is this happening? How can I track down the problem?
Thanks.
Daniel
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: showing window causes EXC_BAD_ACCESS
On Thu, Sep 25, 2008 at 4:17 PM, Daniel Child [EMAIL PROTECTED] wrote: If I press the button in question once, the window dutifully comes up. If I close the window and press the button a second time, I get EXC_BAD_ACCESS. Debugging, I found that both self and mLTableListingsWindow still exist. Sounds like your window is set to release when closed. Uncheck this box in Interface Builder. --Kyle Sluder ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: showing window causes EXC_BAD_ACCESS
THANK YOU! That solved it for all of the windows. On Sep 25, 2008, at 4:25 PM, Kyle Sluder wrote: On Thu, Sep 25, 2008 at 4:17 PM, Daniel Child [EMAIL PROTECTED] wrote: If I press the button in question once, the window dutifully comes up. If I close the window and press the button a second time, I get EXC_BAD_ACCESS. Debugging, I found that both self and mLTableListingsWindow still exist. Sounds like your window is set to release when closed. Uncheck this box in Interface Builder. --Kyle Sluder ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: showing window causes EXC_BAD_ACCESS
On Thu, Sep 25, 2008 at 4:25 PM, Kyle Sluder [EMAIL PROTECTED] wrote: On Thu, Sep 25, 2008 at 4:17 PM, Daniel Child [EMAIL PROTECTED] wrote: If I press the button in question once, the window dutifully comes up. If I close the window and press the button a second time, I get EXC_BAD_ACCESS. Debugging, I found that both self and mLTableListingsWindow still exist. Sounds like your window is set to release when closed. Uncheck this box in Interface Builder. Wandering slightly, but this makes me wonder, why does this flag exist? I can't think of a single reasonable use case for it, and it seems to cause no end to trouble to people who have somehow enabled it without knowing it. It violates the memory management rules and makes programs crash. Is there a good use case for it, or is it just some sort of leftover? Mike ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: showing window causes EXC_BAD_ACCESS
On Fri, Sep 26, 2008 at 12:07 AM, Michael Ash [EMAIL PROTECTED] wrote: Wandering slightly, but this makes me wonder, why does this flag exist? I can't think of a single reasonable use case for it, and it seems to cause no end to trouble to people who have somehow enabled it without knowing it. It violates the memory management rules and makes programs crash. Is there a good use case for it, or is it just some sort of leftover? The bigger problem, I think, is that the flag is enabled by default when creating windows in Interface Builder. There are plenty of advanced options such as the backing store type that aren't configured improperly by default. Perhaps it was originally a way of breaking nib-induced retain cycles? --Kyle Sluder ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
