Hi Tiago,
the memory leak was fixed by commenting out the line as indicated below:
array_pt array_clone (array_pt arr)
{
array_pt arr_clone = array_new(arr->size);
arr_clone->size = arr->size;
arr_clone->count = arr->count;
/* NOT necessary, since we already did that in array_new.
arr_clone->v = (void **)mem_malloc(arr->size*sizeof(void *));
*/
(void)memcpy(arr_clone->v, arr->v, arr_clone->size*sizeof(void *));
return arr_clone;
}
Btw, I have just committed a script, valgrind.sh, which runs Valgrind's
memory leak tool with some default options, places the program's output
in out.txt, and the output of valgrind in valgrind.out.txt.
Do you guys find it useful? If not, should I remove the script again?
Best,
Ulrik
On 05/29/2013 11:46 PM, Ulrik Sandborg-Petersen wrote:
> Hi Tiago,
>
> Thanks for your work. I answer inline below.
>
>
> On 05/29/2013 11:24 PM, Tiago Tresoldi wrote:
>> Hello guys,
>>
>> I started exploring the "library" of acopost (before looking for
>> errors and leaks in the taggers when actually testing them), and I
>> might have found something in array.c.
>>
>> No matter what configuration I use, valgrind accuses a memory leak
>> when using array_clone(). The size of the leak is always the memory
>> allocated to array->v. It could be a false positive, but I am not a
>> good developer enough to rule this out:
>>
>> =======================================
>>
>> ==2811== 64,000 bytes in 1 blocks are definitely lost in loss record
>> 1 of 1
>> ==2811== at 0x402BB7A: malloc (in
>> /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
>> ==2811== by 0x804963E: mem_malloc (mem.c:37)
>> ==2811== by 0x8049090: array_new (array.c:36)
>> ==2811== by 0x8049172: array_clone (array.c:83)
>> ==2811== by 0x8048E99: array_test (acopost_test.c:96)
>> ==2811== by 0x804897F: main (acopost_test.c:131)
>>
>> ====================================
>>
>> 64,000 bytes which, in this case, was exactly the size of array->v in
>> my machine. While no tagger is currently using array_clone(), could
>> you help me trace the source of the leak?
>
>
> I have fixed the memory leak and committed the code and pushed to master.
>
>
>
>>
>> BTW, I am thinking about changing array_get() so that it aborts when
>> asked for a value outside the array's boundaries. We could perform
>> the check during development, removing it when compiling for release.
>> What do you think?
>
>
> Good idea.
>
>
> Best,
>
>
> Ulrik
>
------------------------------------------------------------------------------
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
_______________________________________________
acopost-devel mailing list
acopost-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acopost-devel
