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 <turb...@free.fr> 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 <petr...@mac.com> 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 <z...@mac.com> 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 <admin.szatmari....@gmail.com> 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 <cocoa-dev@lists.apple.com>
>>> 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 releases subImageRef which, 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
