[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;
}
+
}
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Findutils-patches] [PATCH] find memory leak,
Goffredo Baroncelli <=