Re: Must remove submenu when dealloccing NSMenuItem?
Re: Must remove submenu when dealloccing NSMenuItem?
- Subject: Re: Must remove submenu when dealloccing NSMenuItem?
- From: Jerry Krinock <email@hidden>
- Date: Thu, 22 Feb 2007 15:33:36 -0800
- Thread-topic: Must remove submenu when dealloccing NSMenuItem?
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