Thank you very much Ulrik, this project is turning into a good long lesson
to me -- you fixed in a minute a leak that searched for more than one
hour...
I vote for keeping the valgrind script.
Good bye,
Tiago
2013/5/29 Ulrik Sandborg-Petersen <ulr...@emergence.dk>
> 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
>
------------------------------------------------------------------------------
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
