Re: ObjectAlloc and objects that should have been released
Re: ObjectAlloc and objects that should have been released
- Subject: Re: ObjectAlloc and objects that should have been released
- From: Bill Bumgarner <email@hidden>
- Date: Mon, 04 May 2009 11:28:02 -0700
On May 1, 2009, at 8:32 AM, Miles wrote:
For example, I have created a new project where the delegate creates
and
immediately releases a view controller that doesn't have anything in
it at
all. Object alloc still shows a handful of objects as created and
still
living, such as:
# Object Address Category Creation Time Size
Responsible
Library Responsible Caller
1877 0x527c30 GeneralBlock-32 00:01.444 32
ObjectAllocTest
-[ObjectAllocTestAppDelegate applicationDidFinishLaunching:]
1878 0x527540 GeneralBlock-128 00:01.444 128
ObjectAllocTest -[ObjectAllocTestAppDelegate
applicationDidFinishLaunching:]
1879 0x5085f0 GeneralBlock-128 00:01.409 128
ObjectAllocTest start
1880 0x50ca20 GeneralBlock-48 00:01.446 48
ObjectAllocTest
-[MainViewController dealloc]
1881 0x5295c0 GeneralBlock-32 00:01.444 32
ObjectAllocTest
-[ObjectAllocTestAppDelegate applicationDidFinishLaunching:]
1882 0x50ab10 GeneralBlock-48 00:01.446 48
ObjectAllocTest
-[MainViewController dealloc]
1883 0x529970 GeneralBlock-32 00:01.444 32
ObjectAllocTest
-[ObjectAllocTestAppDelegate applicationDidFinishLaunching:]
1884 0x1013000 GeneralBlock-1536 00:01.444 1536
ObjectAllocTest -[ObjectAllocTestAppDelegate
applicationDidFinishLaunching:]
All of the ones that say "[ObjectAllocTestAppDelegate
applicationDidFinishLaunching:]" point to the line where I create
mainMVC.
The ones that say to "[MainViewController dealloc]" point to "[super
dealloc]" (which seems very odd)
Your code is tickling quite a bit of framework code, still. If the
above allocations are truly leaks, that is bad. However, they may
likely be caches, items that briefly live beyond the current release
pool, internal infrastructure that is lazily initialized or any of a
number of other bits of memory used to implement the frameworks.
Just like multithreading, you can't assume anything about what happens
when you call into framework code.
If you want to figure out where this memory is coming from, you'll
need-- at the least-- the allocation backtrace of each block.
But that is likely not very interesting unless they represent a
seriously large consumer of memory and you want to figure out what you
did to trigger the allocation.
The real question is whether or not you see said allocations piling up
over time. If you run your code such that you do said simple task
repeatedly, do you see a pileup of similar allocations? Even if you
do, that still doesn't mean there is a leak -- it could be a cache
that will eventually start evicted items once it hits a certain size
threshold.
Run your code in a loop for a long while and see if you see heap growth.
b.bum
_______________________________________________
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