This workload is just a program I wrote for doing some readdir stuff just creating 10,000 entries in a newly created directory (created outside the program with mkdir command), doing a readdir, and then exit (the program can do more, but that's all I wanted in this case) and then issue a rm -Rf the directory created, and then terminating Ganesha.
I'll be looking into the allocation stack today to see what I can suss out. Frank > -----Original Message----- > From: Daniel Gryniewicz [mailto:d...@redhat.com] > Sent: Monday, May 22, 2017 6:21 AM > To: nfs-ganesha-devel@lists.sourceforge.net > Subject: Re: [Nfs-ganesha-devel] Memory Leaks > > I don't see this with my runs, and I run with ASAN every time. Is there some > workload that triggers this? I usually am only running pyNFS. > > Daniel > > On 05/19/2017 06:48 PM, Frank Filz wrote: > > I need to wrap up this investigation for today, but I just ran the > > following test under valgrind:memcheck: > > > > Start Ganesha using valgrind > > Mount v4 export > > Create 10,000 directory entries in /mnt4/test1/many Issue rm -rf > > /mnt4/test1/many Ctrl-c to terminate. > > > > As an aside note: for FSAL_VFS we may have a file descriptor issue > > somewhere, running with the default 1024 file descriptors is not > > sufficient... > > > > Here is one worrying allocation backtrace: > > > > ==3123== 9,216 bytes in 9 blocks are possibly lost in loss record 410 of 430 > > ==3123== at 0x4C28BF6: malloc (vg_replace_malloc.c:299) > > ==3123== by 0x4879B9: gsh_malloc__ (abstract_mem.h:78) > > ==3123== by 0x48CBA6: nfs4_FSALattr_To_Fattr (nfs_proto_tools.c:3593) > > ==3123== by 0x48C89B: file_To_Fattr (nfs_proto_tools.c:3496) > > ==3123== by 0x46543C: nfs4_op_getattr (nfs4_op_getattr.c:133) > > ==3123== by 0x45EEEF: nfs4_Compound (nfs4_Compound.c:743) > > ==3123== by 0x44B055: nfs_rpc_execute (nfs_worker_thread.c:1291) > > ==3123== by 0x44B86C: worker_run (nfs_worker_thread.c:1563) > > ==3123== by 0x505EF4: fridgethr_start_routine (fridgethr.c:550) > > ==3123== by 0x668B609: start_thread (in /usr/lib64/libpthread-2.22.so) > > ==3123== by 0x7010A4C: clone (in /usr/lib64/libc-2.22.so) > > > > That should have been cleaned up, and if some number of getattr are > > leaking memory, then that's really bad... > > > > All other losses I see look like just not cleaning up all the exports, > > and perhaps especially not cleaning up the PseudoFS properly. > > > > We may also not clean up all the threads on exit. > > > > I will look into this more next week if someone else hasn't already. > > > > Frank > > > > > > --- > > This email has been checked for viruses by Avast antivirus software. > > https://www.avast.com/antivirus > > > > > > ---------------------------------------------------------------------- > > -------- Check out the vibrant tech community on one of the world's > > most engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > _______________________________________________ > > Nfs-ganesha-devel mailing list > > Nfs-ganesha-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel > > > > > ---------------------------------------------------------------------------- -- > Check out the vibrant tech community on one of the world's most engaging > tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Nfs-ganesha-devel mailing list > Nfs-ganesha-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
