Re: looking for a memory problem
Re: looking for a memory problem
- Subject: Re: looking for a memory problem
- From: Fritz Anderson <email@hidden>
- Date: Tue, 17 Jul 2012 10:26:08 -0500
On 17 Jul 2012, at 9:39 AM, Martin Hewitson wrote:
> So I must not be understanding something (likely) because I thought that the autoreleased objects get retained when I add them to the autoreleased array. Then when I set the array to the property, it gets retained and so draining the pool shouldn't result in releasing the objects, should it?
Porting code into and out of garbage collection is Hard.
Stop thinking about "autoreleased" and think in terms of "ownership" instead. How many claims (retain, alloc, container insertions, I won't go through the list here) on an object does _your_ code make, net of relinquishments (release, autorelease) of _your_ claims?
Better yet, use ARC if you possibly can. Even if you have to run on Snow Leopard, and live with unsafe_unretained, most of your worries are taken care of. Bear in mind, though, that while ARC makes reference-counted memory management easier, it doesn't excuse you from understanding it.
> And, in fact, with some judicious log statements I see the objects don't get released when the pool drains, only much later when the document is closed.
Do not log. You'll never catch all of the events. Learn Instruments (even if you have to pause your development) and set "Record reference counts" and "Enable NSZombie detection" in the Allocations instrument. Conduct your audit there.
> And yet, if I don't assign the autoreleased array to the property then I never see the crash and I see the objects being deallocated when the pool drains.
Which won't really tell you anything, even if you've lucked into silencing your crash. Cocoa will retain and release your objects for reasons of its own. If you got the retain count low enough that a particular drain deallocates an object, you may simply have balanced Cocoa-initiated retains that the framework itself will attempt to balance later.
> I'd be grateful if somebody could point out the (stupid) mistake. Currently I'm stumped.
Except for passing through NSSpellChecker, the trace doesn't tell you much. As I just said, it looks as though Cocoa, within its own code, is trying to balance a retain it did itself.
> Could the problem be that I'm using the shared spell checker on multiple threads?
YES. At least it's a very big item on your list of problems. I haven't found any documentation that affirmatively says NSSpellChecker is thread-safe. Therefore it isn't. It's in AppKit, which counts against it, and it manages a UI facility, which excludes it.
Try executing your checks on the main thread. Communicating the results to the calling thread will require some care.
— F
--
Fritz Anderson -- Xcode 4 Unleashed: Now in stores! -- <http://x4u.manoverboard.org/>
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden