findutils-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Findutils-patches] [PATCH] find memory leak


From: Goffredo Baroncelli
Subject: [Findutils-patches] [PATCH] find memory leak
Date: Thu, 15 Dec 2016 22:19:32 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.5.1

Hi All,

(please put me in CC in case of reply because I am not subscribed to the 
mailing list)

I find a memory leak in the find command. In the function 
free_file_system_list() (file fstype.c) the field me_mntroot of the struct 
mount_entry is never free-ed. 

Commit c6148bca89e9465fd6ba3a10d273ec4cb58c2dbe in gnulibs added this field; 
this field is filled by the function read_file_system_list(). To correct this 
problem, we should call the free_mount_entry() function instead of doing the 
free of the fields.

What seems strange to me is that this patch is quite old (August 2015), but 
nobody noticed that. On my machine, find required up to 3GB during the 
"updatedb" !!!

E.g.

# Without the patch, this command requires up to 602MB of memory !!!
$ /usr/bin/time ./find /lib/modules/ -ignore_readdir_race      \( -fstype NFS 
-o -fstype nfs -o -fstype nfs4 -o -fstype afs -o -fstype binfmt_misc -o -fstype 
proc -o -fstype smbfs -o -fstype autofs -o -fstype iso9660 -o -fstype ncpfs -o 
-fstype coda -o -fstype devpts -o -fstype ftpfs -o -fstype devfs -o -fstype mfs 
-o -fstype shfs -o -fstype sysfs -o -fstype cifs -o -fstype lustre_lite -o 
-fstype tmpfs -o -fstype usbfs -o -fstype udf -o -fstype ocfs2 -o      -type d 
-false  \) -prune -o -print0  | wc -l
31.59user 27.17system 0:58.82elapsed 99%CPU (0avgtext+0avgdata 
602476maxresident)k
0inputs+0outputs (0major+150129minor)pagefaults 0swaps

# With the patch, the same command as above requires only 2MB of memory !!!
$ /usr/bin/time ./find /lib/modules/ -ignore_readdir_race      \( -fstype NFS 
-o -fstype nfs -o -fstype nfs4 -o -fstype afs -o -fstype binfmt_misc -o -fstype 
proc -o -fstype smbfs -o -fstype autofs -o -fstype iso9660 -o -fstype ncpfs -o 
-fstype coda -o -fstype devpts -o -fstype ftpfs -o -fstype devfs -o -fstype mfs 
-o -fstype shfs -o -fstype sysfs -o -fstype cifs -o -fstype lustre_lite -o 
-fstype tmpfs -o -fstype usbfs -o -fstype udf -o -fstype ocfs2 -o      -type d 
-false  \) -prune -o -print0  | wc -l
30.94user 26.14system 0:57.14elapsed 99%CPU (0avgtext+0avgdata 2764maxresident)k
0inputs+0outputs (0major+165minor)pagefaults 0swaps


# for curiosity my /lib/modules contains
$ find /lib/modules/ | wc -l
68101

Finally, what about caching the value of read_file_system_list() instead of 
recomputing it every time ? On the basis of my tests I found an impressive gain 
in terms of cpu usage. But what are the cons ?


BR
G.Baroncelli


-- 
gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5


----------------------------


diff --git a/find/fstype.c b/find/fstype.c
index 535f9202..3101853e 100644
--- a/find/fstype.c
+++ b/find/fstype.c
@@ -76,15 +76,10 @@ free_file_system_list (struct mount_entry *p)
     {
       struct mount_entry *pnext = p->me_next;
 
-      free (p->me_devname);
-      free (p->me_mountdir);
-
-      if (p->me_type_malloced)
-       free (p->me_type);
-      p->me_next = NULL;
-      free (p);
+      free_mount_entry(p);
       p = pnext;
     }
+
 }






reply via email to

[Prev in Thread] Current Thread [Next in Thread]