Re: [LTP] mtest01: free memory allocated

[Francesco RUNDO <francesco.rundo@st.com>]

[-- Attachment #1.1: Type: text/plain, Size: 3075 bytes --]

Dear All,

Ok, likely a sort of flag has to be added in the "mtest01.c" 
code.....something like that:

mem_flag=0;
....................

if((mem = (char*)malloc(chunksize)) == NULL) {

.......

exit(1)
}

mem_flag=1:

.......


in order to understand if the malloc() has been executed or not.....and 
then the patch will be:

if ((mem_flag==1)&&(mem != NULL))
{
         free(mem);
         mem_flag=0;
}

Without a patch as above (or like that), in the code of  "mtest01" we 
got scenarios (mainly in the cross architectures like embedded systems) 
in which the LTP run a "malloc()" without "free()".
This is always wrong even though the system resource is enough to cover 
this memory consumption.

Regards
--
FR


Subrata Modak wrote:

>Garrett,
>
>On Mon, 2010-01-04 at 18:10 -0800, Garrett Cooper wrote: 
>  
>
>>On Jan 4, 2010, at 4:55 AM, Francesco RUNDO <francesco.rundo@st.com>  
>>wrote:
>>
>>    
>>
>>>Hi All,
>>>
>>>I'm running LTP (I'm using ltp-full-20090731....but asap I will  
>>>upgrade to latest)  on SH based platforms.
>>>Now, during a test-session. I've noted that the test "mtest01"  
>>>reduced drastically the system memory and after its execution this  
>>>memory wasn't de-allocated.
>>>
>>>I've analysed the mtest01.c code and I've noted that no "free()"  
>>>istruction was associated to the related malloc:
>>>
>>>......
>>>if((mem = (char*)malloc(chunksize)) == NULL) {
>>>......
>>>
>>>I've simply added a "free(mem)" of the allocated memory and the  
>>>issue was addressed successfully.
>>>
>>>I've attached the trivial patch I've developed.
>>>
>>>Best Regards,
>>>--
>>>Francesco
>>>Added missed "free" istruction to release memory previosuly allocated.
>>>Signed-off-by: Francesco Rundo <francesco.rundo@st.com>
>>>--- ltp-full-20090731/testcases/kernel/mem/mtest01/ 
>>>mtest01.c.origin    2009-02-26 13:02:27.000000000 +0100
>>>+++ ltp-full-20090731/testcases/kernel/mem/mtest01/mtest01.c     
>>>2009-12-15 14:03:28.779240000 +0100
>>>@@ -258,5 +258,8 @@
>>>    else
>>>      tst_resm(TPASS, "%llu kbytes allocated only.",  
>>>original_maxbytes/1024);
>>>  }
>>>+
>>>+  free(mem);
>>>+
>>>  exit(0);
>>>}
>>>      
>>>
>>1. Does the version off cvs still have this issue?
>>2. Unless the test exits the code block immediately, I'd definitely do:
>>
>>if (mem)
>>     free (mem);
>>
>>to avoid making a bad free call.
>>    
>>
>
>Have you made any changes to this ? I do not see any commits.
>
>Regards--
>Subrata
>
>  
>
>>Thanks,
>>-Garrett
>>
>>------------------------------------------------------------------------------
>>This SF.Net email is sponsored by the Verizon Developer Community
>>Take advantage of Verizon's best-in-class app development support
>>A streamlined, 14 day to market process makes app distribution fast and easy
>>Join now and get one step closer to millions of Verizon customers
>>http://p.sf.net/sfu/verizon-dev2dev 
>>_______________________________________________
>>Ltp-list mailing list
>>Ltp-list@lists.sourceforge.net
>>https://lists.sourceforge.net/lists/listinfo/ltp-list
>>    
>>
>
>
>  
>

[-- Attachment #1.2: Type: text/html, Size: 4169 bytes --]

[-- Attachment #2: Type: text/plain, Size: 390 bytes --]

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 

[-- Attachment #3: Type: text/plain, Size: 155 bytes --]

_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list