Thanks again for your reply and help.
>> #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?
Unfortunately so, yes. I'll run another backtrace on -dealloc, but I also
created an NSMenuItem subclass for debugging, posed as class so that my
subclass
was used instead of NSMenuItem, and set a break point on its dealloc method,
and
it was called from the AppKit, all internal Cocoa methods. But I'll do that
again to double-check, thanks.
> 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.
I thought that myself, but I don't think this is the case - based on my tests
it
does seem to be an NSMenuItem object getting released, based on:
1) I ran with zombies enabled, and every single time it reported that it was an
NSMenuItem that was having -_bindingAdaptor called on it after release.
2) I set up an NSMenuItem subclass purely for debugging, as I say, and used
-poseAsClass to replace NSMenuItem with my subclass for my tests. In my
subclass
I overrode the -_bindingAdaptor subclass method to NSLog when it was called,
NSLogging -self and -title of the NSMenuItem, too; I also overrode -dealloc not
to call super so that it wouldn't be released (and to NSLog -self and -title
again), so that I could check that it really was this menu item that was having
-_bindingAdaptor called on it after it had been released. And sure enough, my
NSLogs revealed that -dealloc was called and then -_bindingAdaptor was called
on
the same NSMenuItem after the document opened (and obviously it didn't crash in
this test case because I had overridden -dealloc to do nothing in my test
NSMenuItem posed-subclass, again seeming to indicate that it is the menu item
causing the problems).
So it seems that it is an NSMenuItem from the Open Recent menu that is getting
called after it is released, unless I have done something stupid along the way
to create an erroneous result (which of course is possible). And yet it only
affects my app, so clearly I've done something to cause gremlins somewhere.
> Have you run the clang static analyzer (Build and Analyze) on your
> project? Perhaps you are overreleasing something.
I haven't, so I'll look into doing that next - many thanks for the pointer.
Thanks again for the help, I greatly appreciate it.
All the best,
Keith
_______________________________________________
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
