I have a few stupid questions regarding (potential) memory leaks, so please bear with me. First of all, my code is ARC managed.
I tried the Leaks tool of Instruments.
It tells me, if i understand correctly, that I have a leak at this line of my
code:
CFDictionaryRef fileProps = CGImageSourceCopyPropertiesAtIndex( new_image,
0, NULL );
This line is in a method I declared like that:
- (void) loadNextImageWithIndex: (unsigned long) next_index image: (CGImageRef
*) next_image
withProps: (CFDictionaryRef *) next_props
and at the end of the function, I pass fileProps back like so
*next_props = fileProps;
The caller then makes a copy of next_props for later use, and CFRelease's
next_props.
(That copy is also released later.)
So it is unclear to me why the Leaks tool thinks that the above line leaks
memory.
Another area of questions is around CALayer's and images.
I create images like so:
CGImageRef newImageRef = CGImageSourceCreateThumbnailAtIndex( new_image, 0,
(__bridge
CFDictionaryRef) imageOpts );
I store newImageRef in an array (history_of_images).
Then, I assign newImageRef to a CALayer like this:
imgLayer.contents = (__bridge id)(newImageRef);
At some point later, when the layer is no longer part of the layer hierarchy, I
release it like this:
CGImageRelease( history_of_images[k].img );
Can you spot any point in this sequence where there could be a memory leak?
Does any of the assignments I described create a copy?
Should I release CALayer's myself after I have removed it from its super layer?
By the growth of the memory usage of my app I suspect that the images I've been
loading keep lingering on somewhere in memory.
Another area of questions centers around dispatch queues.
The above stuff (loading, thumbnail creation) is, mostly, done in a background
thread via dispatch_async.
I have tried to put an @autoreleasepool around the code that runs in the
background thread, to no avail.
(My code is under ARC.)
But in Instruments, all indications (e.g., Heaviest stack trace) point to
CGImageSourceCreateThumbnailAtIndex, that shows a stack trace like that:
13 libdispatch.dylib 269.42 KB _dispatch_client_callout
12 ArtSaverApp 269.42 KB -[ArtSaverView loadNextImage]
/Users/zach/Code/ArtSaver/ArtSaverView.m:2045
11 ArtSaverApp 269.42 KB -[ArtSaverView
loadNextImageWithIndex:image:withProps:]
/Users/zach/Code/ArtSaver/ArtSaverView.m:2083
10 ImageIO 248.44 KB CGImageSourceCopyPropertiesAtIndex
9 ImageIO 248.44 KB IIOImageSource::copyPropertiesAtIndex(unsigned
long, IIODictionary*)
8 ImageIO 248.30 KB
IIOImageSource::getPropertiesAtIndexInternal(unsigned long, IIODictionary*)
7 ImageIO 244.78 KB IIOImageSource::makeImagePlus(unsigned long,
IIODictionary*)
6 ImageIO 100.08 KB
IIO_Reader_AppleJPEG::initImageAtOffset(CGImagePlugin*, unsigned long, unsigned
long, unsigned long)
5 ImageIO 97.58 KB IIOReadPlugin::callInitialize()
4 ImageIO 93.64 KB AppleJPEGReadPlugin::initialize(IIODictionary*)
3 ImageIO 52.00 KB AppleJPEGReadPlugin::appleJPEGDecodeSetup()
2 AppleJPEG 52.00 KB applejpeg_decode_create
1 libsystem_malloc.dylib 52.00 KB malloc
0 libsystem_malloc.dylib 52.00 KB malloc_zone_malloc
(ArtSaverApp is, of course, my code.)
Similar backtraces show up when I click on the various Malloc leaks in the
Leaks by Backtrace view.
Almost all of them go through CGImageSourceCopyPropertiesAtIndex(), and the
responsible library is
ImageIO.
Thanks a lot in advance for all kinds of insights and hints.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
