[Gluster-devel] valgrind logs for glusterfs-3.4 memory leak

Pranith Kumar Karampuri pkarampu at redhat.com
Fri Oct 17 06:08:49 UTC 2014


hi Kaleb,
       I went through the logs. I don't see anything significant. What 
is the test case that recreates the mem-leak? May be I can try it on my 
setup and get back to you?

Pranith
On 10/15/2014 08:57 PM, Kaleb S. KEITHLEY wrote:
> As mentioned in the Gluster Community Meeting on irc today, here are 
> the glusterfs client side valgrind logs. By 'glusterfs client side' I 
> specifically mean the glusterfs fuse bridge daemon on the client.
>
> http://download.gluster.org/pub/gluster/glusterfs/dynamic-analysis/valgrind-3.4-memleak/ 
>
>
> The basic test is, simply, mount the gluster volume, make a deep 
> directory path on the volume, e.g. /mnt/a/b/c/d/e/f/g, do three or 
> five `ls -R /mnt`, and unmount.
>
> tmp[35]/glusterfs.fuse.out are the logs from three or five ls -R.
>
> tmp[35]+/glusterfs.fuse.out are the logs as above, but with the 
> addition that the directories are populated with a few files.
>
> Notice that, e.g. both tmp[35]/glusterfs.fuse.out show approximately 
> the same amount of {definitely,indirectly,possibly} lost memory. I.e. 
> the number of `ls -R` invocations did not affect how much memory was 
> leaked.
>
> The same is true for tmp[35]+/glusterfs.fuse.out. I.e. more `ls -R` 
> did not affect the amount of memory leaked, _but_ notice that when the 
> directories are populated with files that more memory was leaked, 
> across the board, than when the directories were empty.
>
> Make sense? Any questions, don't hesitate to ask.
>
> Thanks,
>



More information about the Gluster-devel mailing list