[Gluster-devel] Memory deallocation question about iov_dup

Xavier Hernandez xhernandez at datalab.es
Tue Oct 30 10:36:13 UTC 2012


Hello Gustavo,

first of all you don't need to call iov_dup() unless you modify it 
before WIND() or you need it at the callback. If you need to make some 
changes to the vector list, then you mush call iov_dup(), make the 
changes, call one or more WINDs() (if needed) and free it with 
GF_FREE(). If you use the vector list in the callback, you must not free 
it until the callback. In all other cases, you can pass the same pointer 
you received to the next translator through a WIND() without allocating 
a new one.

On the other hand, I'm not sure this is the real cause of the memory 
leak. iov_dup() only duplicates the array of pointers, but not the 
buffers themselves. If you are also copying the buffers, then you must 
also free them. The best way is calling iov_free(), which releases both 
buffers and the array of pointers.

Regards,

Xavi

Al 30/10/12 11:16, En/na Gustavo Bervian Brand ha escrit:
> Hello,
>
>   I am facing a big memory leak and I believe the responsible parts 
> are the iov_dups I am doing while reading a file to write it somewhere 
> else, because the system's memory is running out according to the file 
> size I am dealing with.
>   Before calling a WIND that needs the vector as param I do a 
> iov_dup() to a local pointer and this goes as the WIND parameter.
>
>   To correctly deallocate this, the best thing is a GF_FREE after the 
> WIND or saving the pointer to local and deallocate it at the callback? 
> Or any other approach, like only before the UNWIND after the sequence 
> of WINDs(where I am deallocating the local, for example)?
>
> Thanks,
> Gustavo Brand
> ---------------------------------------------------------------------------------
>
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at nongnu.org
> https://lists.nongnu.org/mailman/listinfo/gluster-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20121030/bc60d603/attachment-0001.html>


More information about the Gluster-devel mailing list