Re: Must remove submenu when dealloccing NSMenuItem?
Re: Must remove submenu when dealloccing NSMenuItem?
- Subject: Re: Must remove submenu when dealloccing NSMenuItem?
- From: Andy Lee <email@hidden>
- Date: Thu, 22 Feb 2007 20:15:20 -0500
Jerry, I took a quick look and the code seems to support your
conclusion -- that when NSMenus are constructed using the lazy
delegate mechanism, something is being over-retained. I think the
"something" is more likely the NSMenuItems that are added to the
submenus, since the difference is that in the non-lazy case *we*
instantiate the menu item and in the lazy case Apple does. I can
easily imagine an accidental extra retain on Apple's part.
Off-topic or not, I'd vote that you should get your money back. :)
--Andy
On Feb 22, 2007, at 6:33 PM, Jerry Krinock wrote:
on 07/02/22 7:24, Andy Lee at email@hidden wrote:
If you'd like to start adding back code to see if you can
reproduce the
problem, my quick test is here:
http://homepage.mac.com/aglee/MenuScratch.tgz
OK Andy, since you were kind enough to that together, I decided I'd
spend a
few hours on it. My modified not-so-quick test is here:
http://sheepsystems.com/engineering/projects/MenuScratch.zip
SUMMARY
This should be of interest to anyone who is using lazily-created
contextual
menus.
As Andy said, his demo shows that everything gets deallocced fine,
however
as he noted, his demo is not lazily creating menus. After I
modified the
project to lazily create menus, I see the same problem as described
in my
original post. Furthermore, I have now found that the workaround I
described yesterday also solves a related problem I discovered last
summer,
which Apple DTS could not understand when I submitted a support
incident.
DESCRIPTION
The project now puts up an NSOutlineView, as my real project does.
But this
outline has one item, a lazily-created contextual menu. The
contextual menu
will go 5 levels deep. (Sorry, memory management in the
AppDelegate is
ad-hoc; I did not bother with accessors or dealloccing the
auxiliary objects
which are used to demo the problem.)
The project is compiled to use my workaround, USE_JERRYS_WORKAROUND
#defined. Run the project and right-click the contextual menu.
The log
will show when SSMenu objects are initialized and when they are
deallocced.
To make it easier to see, I also implemented a mutable array of
pointers to
the SSMenus. Whenever an menu is initialized, it is added to the
array.
Whenever an SSMenu is deallocced, it is removed from the array.
The array
is printed to the log whenever the menu ends tracking, and it is
reprinted
400 milliseconds later, so you can see which SSMenus were
deallocced. You
see that all menus are deallocced, as desired. Quit the app.
Then, open SSMenu.m and un-#define USE_JERRYS_WORKAROUND. Then
compile the
project and run it again, right-clicking to create a contextual
menu. You
will see that only the highest-level menu is deallocced, but the
lazily-created submenus are ^not^ deallocced.
BUT WAIT, THERE'S MORE
Show some contextual menus several times. Then, keep your eye on
the log
and Quit the app. Look at that!! You see it goes CRAZY
initializing menus,
all the way out to level 5, even if you never traversed to level 5.
So, now I have a further conclusion that this bug/leak is not only
responsible for leaking and occasional crashes, but it is also
responsible
for a problem I wrote about last summer, and no one knew the answer to
"Crazy Instead Of Lazy":
http://www.cocoabuilder.com/archive/message/cocoa/2006/7/20/168013
At the time, I implemented a workaround by using an instance BOOL
_beLazy,
some of which you can see in the original code I posted to this list
yesterday. Last autumn, I submitted this as a support incident to
Apple
DTS, but they couldn't find the root cause, and I eventually moved
on to
more pressing problems after I discovered that if I set _beLazy in an
additional situation, it reduced the crashes further, so that they
were very
rare.
Now...guess what...I just tested my real product, with the new
USE_JERRYS_WORKAROUND, but without my old _beLazy workaround, and
the "Crazy
Instead of Lazy" problem is gone also.
Here's a joke: Has anyone ever had any luck getting their $195 back
from
Apple after they couldn't solve the problem, and you found a bug in
their
framework three months later? (Reply privately so you don't get
flamed for
being off topic.)
More seriously, if you Andy or anyone else wants to look at this
again and
prove me wrong, I'd appreciate it.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden