Hi,
A user reported that 1.0.12 is leaking memory like crazy, and I can reproduce
it here. Running valgrind (with the Omega tool) on mountd reveals that the
new blkid code is the culprit, but almost every single leak seems to be
_allocated_ at the same spot, namely at blkid_probe_all_new() time.
A typical leaks goes like this:
==9584== Loss Record 7: Leaked 974848 (0xEE000) bytes in 14 blocks
==9584== at 0x4030D80: blkid_verify (probe.c:914)
==9584== by 0x402D981: blkid_get_dev (devname.c:82)
==9584== by 0x402DBDE: probe_one (devname.c:145)
==9584== by 0x402E7CB: probe_all (devname.c:510)
==9584== by 0x402E983: blkid_probe_all_new (devname.c:551)
==9584== by 0x804D26E: get_uuid (cache.c:173)
==9584== by 0x804DDA7: dump_to_cache (cache.c:461)
==9584== by 0x804E31A: cache_export_ent (cache.c:596)
==9584== by 0x804E454: cache_export (cache.c:625)
==9584== by 0x804B106: get_rootfh (mountd.c:421)
==9584== by 0x804AE41: mount_mnt_3_svc (mountd.c:350)
==9584== by 0x8055A1A: rpc_dispatch (rpcdispatch.c:55)
==9584== Blocks allocated
==9584== at 0x401CDA0: malloc (vg_replace_malloc.c:149)
==9584== by 0x402F28B: get_buffer (probe.c:56)
==9584== by 0x4030B64: blkid_verify (probe.c:862)
==9584== by 0x402D981: blkid_get_dev (devname.c:82)
==9584== by 0x402DBDE: probe_one (devname.c:145)
==9584== by 0x402E7CB: probe_all (devname.c:510)
==9584== by 0x402E983: blkid_probe_all_new (devname.c:551)
==9584== by 0x804D26E: get_uuid (cache.c:173)
==9584== by 0x804DDA7: dump_to_cache (cache.c:461)
==9584== by 0x804E31A: cache_export_ent (cache.c:596)
==9584== by 0x804E454: cache_export (cache.c:625)
==9584== by 0x804B106: get_rootfh (mountd.c:421)
Over time, this amounts to gigabytes of RAM on a busy server. Either the
blkid library is generally really leaky (in which case we probably shouldn't
be using it until it's fixed), or we're using it wrong somehow. :-)
/* Steinar */
--
Homepage: http://www.sesse.net/
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Tue, Mar 06, 2007 at 01:52:30PM +0100, Steinar H. Gunderson wrote:
> Over time, this amounts to gigabytes of RAM on a busy server. Either the
> blkid library is generally really leaky (in which case we probably shouldn't
> be using it until it's fixed), or we're using it wrong somehow. :-)
I found the leaks in libblkid (see the separate e-mail I sent). This patch
fixes a minor leak in mountd itself, and with the patch applied and a fixed
libblkid, it appears that mountd is no longer leaking memory.
--- nfs-utils-1.0.12.orig/support/export/client.c 2007-03-06 15:51:39.000000000 +0100
+++ nfs-utils-1.0.12/support/export/client.c 2007-03-06 15:51:53.000000000 +0100
@@ -329,6 +329,7 @@
strcat(new, ",");
strcat(new, cp);
}
+ free(old);
return new;
}
/* Steinar */
--
Homepage: http://www.sesse.net/
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs