Thanks again to both of you for your help. After stripping out my application
subclass, document controller subclass, and then stripping out swathes of my
NSDocument subclass, I finally tracked it down to something in the
-readFromURL:... code (which makes sense seeing as the crash occurred after the
document opened). My file format is a package format, and at the end of the
-readFromURL:... code, I was using an NSTask to make an internal zipped backup
of the main XML file, so that it could be retrieved, and the project opened, if
the main XML file ever became corrupted. And this was the problem: spawning an
NSTask to create a zip from within -readFromURL:... More specifically, it seems
to be the call to -waitUntilExit. So I just need to find a better internal
backup solution or move the XML->zip backup to code that gets called after
everything has been loaded (probably the former). Very strange that it had this
particular effect, and only on the use of the Help menu to open a project, but
at least I've found the culprit.
Thanks again for taking time to help, much appreciated!
All the best,
Keith
----- Original Message ----
From: Kyle Sluder <kyle.slu...@gmail.com>
To: Keith Blount <keithblo...@yahoo.com>
Cc: cocoa-dev@lists.apple.com
Sent: Sat, November 6, 2010 10:14:17 PM
Subject: Re: Over-released NSMenuItem on using "Open Recent" via Help menu
search
On Sat, Nov 6, 2010 at 1:47 PM, Keith Blount <keithblo...@yahoo.com> wrote:
> Thanks! I just tried that but the menu item is created and destroyed by the
> AppKit as far as I can see. The offending object:
>
> objc[88279]: FREED(id): message _bindingAdaptor sent to freed
object=0x1a4cccd0
>
> Checking that object address in Instruments:
>
> #CategoryEvent TypeRefCtTimestampAddressSizeResponsible LibraryResponsible
> Caller
> 0NSMenuItemMalloc13059475443200x1a4cccd064AppKit-[NSMenu
> insertItemWithTitle:action:keyEquivalent:atIndex:]
> 1NSMenuItemFree03289974881280x1a4cccd0-64AppKit-[NSMenuItem dealloc]
Hmm, these are the only alloc and free events recorded in Instruments
for that address? What's the backtrace on that call to -[NSMenuItem
dealloc]?
A bit of digging with -instancesRespondToSelector: indicates that
-_bindingAdaptor is defined in a private NSObject category. So that
means that the fact that it's a deallocated NSMenuItem might be a red
herring. If something else was allocated at that address but
prematurely freed, that could be the thing that the offending code is
trying to send the -_bindingAdaptor message.
Have you run the clang static analyzer (Build and Analyze) on your
project? Perhaps you are overreleasing something.
> (Is there a way to check the specific object that's calling it? The above is
>the
> only information I could find running Allocations.)
Not really. All sorts of optimizations will mean that values like
"self" won't remain in place for you to find them.
--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 arch...@mail-archive.com
