Re: Cocoa application memory leak check
Re: Cocoa application memory leak check
- Subject: Re: Cocoa application memory leak check
- From: Ken Ferry <email@hidden>
- Date: Mon, 27 Apr 2009 03:46:16 -0700
.. but speaking of static analyzers, try <
http://clang.llvm.org/StaticAnalysis.html>.
I don't think it reasons about malloc and free, but it does reason about
-retain and -release.
-Ken
On Mon, Apr 27, 2009 at 3:14 AM, WT <email@hidden> wrote:
> I think you're expecting a bit too much from Instruments. I may be wrong,
> but I think Instruments is not a static analyzer. It only checks for leaks
> as they occur, that is, at runtime. Thus, if parts of your code do not
> execute at runtime during a given session, Instruments won't see them and
> won't care about them. The way to test for leaks such as the one you pointed
> out is to run Instruments several times, each time forcing a particular path
> through your code's runtime profile. In your specific example, you'd run
> your application under Instruments twice, the first time making sure that
> the condition is true, the second time making sure that the condition is
> false. You could force the condition to be true or false by interacting with
> your application at runtime (for instance, if the condition is tied to a
> checkbox, you'd check the box on or off), or by temporarily setting the
> condition to true or false in code, explicitly.
>
> Wagner
>
>
> On Apr 27, 2009, at 11:33 AM, XiaoGang Li wrote:
>
> Hello, list
>> I try to check my Cocoa application memory leak issue using Instruments.
>> here I have a question here:
>> for example:
>> if(conditions == true){
>> void *buffer1 = malloc(32);
>> buffer1 = NULL;
>> } else {
>> void *buffer2 = malloc(32);
>> buffer2 = NULL;
>> }
>> the Instruments (leaks) can not find out the buffer2 leak, because this
>> part
>> is not executed. So, how to check this kind of memory leak? Thanks.
>>
>> Xiaogang
>>
> _______________________________________________
>
> 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
>
_______________________________________________
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