On Thu, May 10, 2007 at 02:57:46PM +0200, Rik Theys wrote: > In attach the valgrind output with libc6-dbg installed and /etc/nsswitch > configured to use files for netgroups instead of ldap. The memory leaks > is still there.
I've looked through the loss records while waiting for the Omega reports: > ==19854== 6,150 bytes in 256 blocks are definitely lost in loss record 15 of > 20 > ==19854== at 0x401D38B: malloc (vg_replace_malloc.c:149) > ==19854== by 0x804DFB1: client_compose (client.c:309) > ==19854== by 0x804BB72: auth_authenticate (auth.c:85) > ==19854== by 0x804A527: get_rootfh (mountd.c:384) > ==19854== by 0x804A8CB: mount_mnt_3_svc (mountd.c:349) > ==19854== by 0x8052BBD: rpc_dispatch (rpcdispatch.c:55) > ==19854== by 0x804BA4F: mount_dispatch (mount_dispatch.c:83) > ==19854== by 0x41226C1: svc_getreq_common (svc.c:465) > ==19854== by 0x4122716: svc_getreqset (svc.c:376) > ==19854== by 0x804D899: my_svc_run (svc_run.c:90) > ==19854== by 0x804B6F8: main (mountd.c:722) This one is rather smallish. I believe it's the bug that's already patched in 1.0.12-3. > ==19854== 168,672 bytes in 2,745 blocks are definitely lost in loss record 19 > of 20 > ==19854== at 0x401D38B: malloc (vg_replace_malloc.c:149) > ==19854== by 0x80531D7: xmalloc (xcommon.c:152) > ==19854== by 0x804ECD6: hostent_dup (hostname.c:124) > ==19854== by 0x804EEC7: get_reliable_hostbyaddr (hostname.c:253) > ==19854== by 0x804DF23: client_compose (client.c:253) > ==19854== by 0x804BB72: auth_authenticate (auth.c:85) > ==19854== by 0x804AEB9: mount_umnt_1_svc (mountd.c:225) > ==19854== by 0x8052BBD: rpc_dispatch (rpcdispatch.c:55) > ==19854== by 0x804BA4F: mount_dispatch (mount_dispatch.c:83) > ==19854== by 0x41226C1: svc_getreq_common (svc.c:465) > ==19854== by 0x4122716: svc_getreqset (svc.c:376) > ==19854== by 0x804D899: my_svc_run (svc_run.c:90) This one looks like a genuine leak. client_compose() seems to do a host lookup without actually freeing it. Could you try adding a "free(he);" to the bottom of client_compose() (support/export/client.c:253)? > ==19854== 1,405,440 bytes in 2,745 blocks are definitely lost in loss record > 20 of 20 > ==19854== at 0x401D38B: malloc (vg_replace_malloc.c:149) > ==19854== by 0x401D415: realloc (vg_replace_malloc.c:306) > ==19854== by 0x4267B62: ??? > ==19854== by 0x4119200: innetgr (getnetgrent_r.c:352) > ==19854== by 0x804DD54: client_check (client.c:390) > ==19854== by 0x804DF7A: client_compose (client.c:260) > ==19854== by 0x804BB72: auth_authenticate (auth.c:85) > ==19854== by 0x804AEB9: mount_umnt_1_svc (mountd.c:225) > ==19854== by 0x8052BBD: rpc_dispatch (rpcdispatch.c:55) > ==19854== by 0x804BA4F: mount_dispatch (mount_dispatch.c:83) > ==19854== by 0x41226C1: svc_getreq_common (svc.c:465) > ==19854== by 0x4122716: svc_getreqset (svc.c:376) This one actually looks internal to glibc, so I'm not sure if it can actually be fixed in nfs-utils. innetgr() is somewhat undocumented, but it looks like it's supposed to take in a few pointers and just return a true/false value; there's no pointer returned back to the mountd code, so I'm not sure how one could change anything in mountd to make this leak go away. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
