Re: Avoiding leaks with "initWithCGImage"
To be clear, CGImageForProposedRect doesn’t have ‘Create’ in the name. So the
'Create Rule' doesn’t apply. But it is an easy thing to overlook.
—Rob
> On Aug 24, 2023, at 2:35 AM, JPH wrote:
>
> Thanks to all of you
> The CFRelease(imageRef); was the problem and the CFRelease(subImageRef); is
> OK
> My fault was then to apply the old days « Create rule » , bypassing ARC !
> I was misled by Instruments/Leaks which reports a leak, which meant to me
> that I had to look for a missing release, not an over-release !!
> Very confusing !
>
> Thank again
> Happy Dog Days ( 41°C / 105,8°F here ! )
>
> JP
>
>
>
>> Le 24 août 2023 à 00:55, Rob Petrovec a écrit :
>>
>> CGImageForProposedRect returns an autoreleased CGImageRef, so your
>> CFRelease(imageRef) is an overrelease and likely the cause of your problem.
>> The rest of the code looks fine, including the release of subImageRef (if it
>> was uncommented).
>>
>> —Rob
>>
>> Le 24 août 2023 à 01:11, Alex Zavatone a écrit :
>>
>> Got a small sample we could play with? I would expect the crash on explicit
>> release as it would cause a double release.
>>
>> I tend to ignore I strums to with leaks and use the Memory Graph debugger
>> religiously.
>>
>> If you have a little sample showing this, I would be happy to test a bit
>> with it.
>>
>> Cheers,
>> Alex Zavatone
>
>
> Le 24 août 2023 à 07:44, Sandor Szatmari a
> écrit :
>
> You mention ARC… aren’t you not supposed to explicitly release objects under
> ARC? Am I misunderstanding?
>
> Sandor
>
>>
>>> On Aug 23, 2023, at 4:47 PM, JPH via Cocoa-dev
>>> wrote:
>>>
>>> Hello friends,
>>>
>>> The enclosed procedure is producing a NSImage from another NSImage, by
>>> cropping in a NSRect.
>>> The resulting sub-Image feeds an imageView in the APP Interface and the
>>> may change frequently, then being hopefully disposed by ARC
>>> The last line of the procedure :
>>> NSImage *subImage = [[NSImage alloc] initWithCGImage:subImageRef
>>> size:NSZeroSize];
>>> Generates a leak problem.
>>>
>>> it is quite unclear if i should release or not the subImageRef.
>>>
>>> If I release, the app crashes soon after.
>>> If I don’t release, Instrument/Leaks reports a leak of subImageRef after
>>> each call.
>>>
>>> Obviously, ARC never releasessubImageRefwhich, as far as I
>>> understand, is owned by the subImage after the call.
>>>
>>> Digging the web , apple doc, and various AI, did not provide a solution to
>>> this dilemme.
>>>
>>> I would greatly appreciate some help on this
>>>
>>> Happy summer..
>>> JP
>>>
>>> C
>>> //=
>>> + (NSImage *)getSubImageFromImage:(NSImage *)image atRect:(NSRect)rect
>>> //=
>>> {
>>> // Convert the NSImage to a CGImageRef
>>> CGImageRef imageRef= nil, subImageRef= nil;
>>> imageRef = [image CGImageForProposedRect:NULL context:nil hints:nil];
>>> if (imageRef == nil ) { return nil; } // Failed to create CGImageRef
>>> // Get the subimage from the CGImageRef
>>> subImageRef = CGImageCreateWithImageInRect(imageRef, rect);
>>> CFRelease(imageRef);
>>> if(subImageRef == nil ) { return nil; } // Failed to create subImageRef
>>> // Convert the subimage CGImageRef to an NSImage
>>> NSImage *subImage = [[NSImage alloc] initWithCGImage:subImageRef
>>> size:NSZeroSize];
>>> // CFRelease(subImageRef); // it is quite unclear if i should release the
>>> subImageRef
>>> //If I release, the app crashes soon after.
>>> // If i dont release Instrument/Leaks report a leak at next call.
>>> // The subImage goes to a NSbutton in the interface, and will also soon be
>>> replaced by another one, producing a leak of subImageRef
>>>
>>> return subImage;
>>> }// getSubImageFromImage
>>> ___
>>>
>>> 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/petrock%40mac.com
>>>
>>> This email sent to petr...@mac.com
>>
>
___
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
Re: Avoiding leaks with "initWithCGImage"
ARC only affects Objective-C objects. It has no effect on CF objects like
CGImageRefs, CFArrayRefs, CFDictionaryRefs etc. If you play with CF objects in
an ARC app you still need to release them. You don’t need to release Obj-C
objects and the compiler will warn you if you try to.
—Rob
> On Aug 23, 2023, at 11:44 PM, Sandor Szatmari via Cocoa-dev
> wrote:
>
> You mention ARC… aren’t you not supposed to explicitly release objects under
> ARC? Am I misunderstanding?
>
> Sandor
>
>> On Aug 23, 2023, at 18:48, JPH via Cocoa-dev
>> wrote:
>>
>> Hello friends,
>>
>> The enclosed procedure is producing a NSImage from another NSImage, by
>> cropping in a NSRect.
>> The resulting sub-Image feeds an imageView in the APP Interface and the
>> may change frequently, then being hopefully disposed by ARC
>> The last line of the procedure :
>> NSImage *subImage = [[NSImage alloc] initWithCGImage:subImageRef
>> size:NSZeroSize];
>> Generates a leak problem.
>>
>> it is quite unclear if i should release or not the subImageRef.
>>
>> If I release, the app crashes soon after.
>> If I don’t release, Instrument/Leaks reports a leak of subImageRef after
>> each call.
>>
>> Obviously, ARC never releasessubImageRefwhich, as far as I
>> understand, is owned by the subImage after the call.
>>
>> Digging the web , apple doc, and various AI, did not provide a solution to
>> this dilemme.
>>
>> I would greatly appreciate some help on this
>>
>> Happy summer..
>> JP
>>
>> C
>> //=
>> + (NSImage *)getSubImageFromImage:(NSImage *)image atRect:(NSRect)rect
>> //=
>> {
>> // Convert the NSImage to a CGImageRef
>> CGImageRef imageRef= nil, subImageRef= nil;
>> imageRef = [image CGImageForProposedRect:NULL context:nil hints:nil];
>> if (imageRef == nil ) { return nil; } // Failed to create CGImageRef
>> // Get the subimage from the CGImageRef
>> subImageRef = CGImageCreateWithImageInRect(imageRef, rect);
>> CFRelease(imageRef);
>> if(subImageRef == nil ) { return nil; } // Failed to create subImageRef
>> // Convert the subimage CGImageRef to an NSImage
>> NSImage *subImage = [[NSImage alloc] initWithCGImage:subImageRef
>> size:NSZeroSize];
>> // CFRelease(subImageRef); // it is quite unclear if i should release the
>> subImageRef
>> //If I release, the app crashes soon after.
>> // If i dont release Instrument/Leaks report a leak at next call.
>> // The subImage goes to a NSbutton in the interface, and will also soon be
>> replaced by another one, producing a leak of subImageRef
>>
>> return subImage;
>> }// getSubImageFromImage
>> ___
>>
>> 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/admin.szatmari.net%40gmail.com
>>
>> This email sent to admin.szatmari@gmail.com
> ___
>
> 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/petrock%40mac.com
>
> This email sent to petr...@mac.com
___
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
Re: Avoiding leaks with "initWithCGImage"
Thanks to all of you
The CFRelease(imageRef); was the problem and the CFRelease(subImageRef); is OK
My fault was then to apply the old days « Create rule » , bypassing ARC !
I was misled by Instruments/Leaks which reports a leak, which meant to me that
I had to look for a missing release, not an over-release !!
Very confusing !
Thank again
Happy Dog Days ( 41°C / 105,8°F here ! )
JP
> Le 24 août 2023 à 00:55, Rob Petrovec a écrit :
>
> CGImageForProposedRect returns an autoreleased CGImageRef, so your
> CFRelease(imageRef) is an overrelease and likely the cause of your problem.
> The rest of the code looks fine, including the release of subImageRef (if it
> was uncommented).
>
> —Rob
>
> Le 24 août 2023 à 01:11, Alex Zavatone a écrit :
>
> Got a small sample we could play with? I would expect the crash on explicit
> release as it would cause a double release.
>
> I tend to ignore I strums to with leaks and use the Memory Graph debugger
> religiously.
>
> If you have a little sample showing this, I would be happy to test a bit with
> it.
>
> Cheers,
> Alex Zavatone
Le 24 août 2023 à 07:44, Sandor Szatmari a écrit
:
You mention ARC… aren’t you not supposed to explicitly release objects under
ARC? Am I misunderstanding?
Sandor
>
>> On Aug 23, 2023, at 4:47 PM, JPH via Cocoa-dev
>> wrote:
>>
>> Hello friends,
>>
>> The enclosed procedure is producing a NSImage from another NSImage, by
>> cropping in a NSRect.
>> The resulting sub-Image feeds an imageView in the APP Interface and the
>> may change frequently, then being hopefully disposed by ARC
>> The last line of the procedure :
>> NSImage *subImage = [[NSImage alloc] initWithCGImage:subImageRef
>> size:NSZeroSize];
>> Generates a leak problem.
>>
>> it is quite unclear if i should release or not the subImageRef.
>>
>> If I release, the app crashes soon after.
>> If I don’t release, Instrument/Leaks reports a leak of subImageRef after
>> each call.
>>
>> Obviously, ARC never releasessubImageRefwhich, as far as I
>> understand, is owned by the subImage after the call.
>>
>> Digging the web , apple doc, and various AI, did not provide a solution to
>> this dilemme.
>>
>> I would greatly appreciate some help on this
>>
>> Happy summer..
>> JP
>>
>> C
>> //=
>> + (NSImage *)getSubImageFromImage:(NSImage *)image atRect:(NSRect)rect
>> //=
>> {
>> // Convert the NSImage to a CGImageRef
>> CGImageRef imageRef= nil, subImageRef= nil;
>> imageRef = [image CGImageForProposedRect:NULL context:nil hints:nil];
>> if (imageRef == nil ) { return nil; } // Failed to create CGImageRef
>> // Get the subimage from the CGImageRef
>> subImageRef = CGImageCreateWithImageInRect(imageRef, rect);
>> CFRelease(imageRef);
>> if(subImageRef == nil ) { return nil; } // Failed to create subImageRef
>> // Convert the subimage CGImageRef to an NSImage
>> NSImage *subImage = [[NSImage alloc] initWithCGImage:subImageRef
>> size:NSZeroSize];
>> // CFRelease(subImageRef); // it is quite unclear if i should release the
>> subImageRef
>> //If I release, the app crashes soon after.
>> // If i dont release Instrument/Leaks report a leak at next call.
>> // The subImage goes to a NSbutton in the interface, and will also soon be
>> replaced by another one, producing a leak of subImageRef
>>
>> return subImage;
>> }// getSubImageFromImage
>> ___
>>
>> 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/petrock%40mac.com
>>
>> This email sent to petr...@mac.com
>
___
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
