Re: Cocoa application memory leak check
Re: Cocoa application memory leak check
- Subject: Re: Cocoa application memory leak check
- From: XiaoGang Li <email@hidden>
- Date: Tue, 28 Apr 2009 09:05:03 +0800
Thank you, WT and Ken Ferry.
Yes, I also think Instruments is a static analyzer, so I am seeking a better
tool for memory leak check, which support both static and dynamic checker.
Hi, Ken, I have tried the static analyzers you mentioned. But it can not
handle this kind of case, for example:
//code start
void *buffer1 = malloc(32);
memset(buffer1,0,32);
buffer1 = NULL;
void *buffer2 = malloc(32);
buffer2 = NULL;
void *buffer3 = malloc(32);
free(buffer3);
buffer3 = NULL;
//code end
the results in this analysis run is werid. it only report the buffer2, the
buffer1 is not checked out. Is it a bug for this tool? or do I also expect
too much from this this checker.
Thanks.
2009/4/27 Ken Ferry <email@hidden>
> .. 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