In nsswitch.c:519 (CVS file version 1.61), new_service is malloc()ed but never free()d. This results in minor memory leaks (~300 bytes) according to valgrind. The valgrind trace is below. I tried fixing this one myself but failed miserably :) ==2459== 312 (72 direct, 240 indirect) bytes in 2 blocks are definitely lost in loss record 3 of 11 ==2459== at 0x401B45B: malloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==2459== by 0x43B67E8: nss_parse_service_list (nsswitch.c:519) ==2459== by 0x43B60D8: __nss_database_lookup (nsswitch.c:134) ==2459== by 0x450F1DB: ??? ==2459== by 0x451075C: ??? ==2459== by 0x43766B3: getpwnam_r@@GLIBC_2.1.2 (getXXbyYY_r.c:207) ==2459== by 0x43761CE: getpwnam (getXXbyYY.c:103) ==2459== by (my program)
First of all, this is no leak. The memory is allocated once to hold global state. It's normally not freed. But for memory debuggers it is. Which is why I doubt that's a real problem. You have to provide a small, self-contained test case.
Apologies, this was merely a misunderstanding on my part. I had asked in #glibc whether it was unexpected behaviour and was told to bug it here. Looking again, subsequent calls do not cause it to allocate any more memory, so I can understand your point. Thanks for such a quick reply, I'll know to ignore it in future :)
Created attachment 1535 [details] Test file showing memory leak getpwnam_r calls nss_parse_service_list which allocates memory which it doesn't free.
The attached file demonstrates the problem. If this global data not normally freed, then shouldn't it be freed in __libc_freeres , so as to be kind to debuggers ?? Sure it's not a "big" problem, but it's annoying as it can mask bigger genuine leaks.
libc frees the memory already. I cannot see anything wrong. You'll have to provide a test case. In source form.
No reply in 6+ months. Closing.
I think the memory is leaked in nis/nis_compat/compat-{grp,initgroups,pwd,spwd}.c. All of them contain static service_user *ni, which is initialized by init_nss_interface() -> __nss_database_lookup ("group_compat", NULL, "nis", &ni). This memory does not seem to be freed by __libc_freeres().
I have to confirm that some memory is not freed, at least on my Debian systems. That's my /etc/nsswitch.conf: passwd: compat group: compat shadow: compat hosts: files dns networks: files protocols: db files services: db files ethers: db files rpc: db files netgroup: nis That's the output of Valgrind: ==4608== HEAP SUMMARY: ==4608== in use at exit: 320 bytes in 22 blocks ==4608== total heap usage: 1,558 allocs, 1,536 frees, 615,807 bytes allocated ==4608== ==4608== 160 (40 direct, 120 indirect) bytes in 1 blocks are definitely lost in loss record 21 of 22 ==4608== at 0x4023F50: malloc (vg_replace_malloc.c:236) ==4608== by 0x4123A03: nss_parse_service_list (nsswitch.c:622) ==4608== by 0x4124146: __nss_database_lookup (nsswitch.c:164) ==4608== by 0x4594EAB: ??? ==4608== by 0x4595B6C: ??? ==4608== by 0x40DD7F4: getpwuid_r@@GLIBC_2.1.2 (getXXbyYY_r.c:253) ==4608== by 0x804A941: userNameFromId (osdeps_posix.c:622) ==4608== by 0x804A9EC: osp_trustee_find (osdeps_posix.c:642) ==4608== by 0x80D0225: consdb_process_trustee (consdb_util.c:286) ==4608== by 0x80CDAFA: consdb_wctx_data (consdb2.c:355) ==4608== by 0x80D3D28: calcItemHashes (consalgo.c:603) ==4608== by 0x80D3ED3: calcSimpleGroupHashes (consalgo.c:643) ==4608== ==4608== 160 (40 direct, 120 indirect) bytes in 1 blocks are definitely lost in loss record 22 of 22 ==4608== at 0x4023F50: malloc (vg_replace_malloc.c:236) ==4608== by 0x4123A03: nss_parse_service_list (nsswitch.c:622) ==4608== by 0x4124146: __nss_database_lookup (nsswitch.c:164) ==4608== by 0x4593F2B: ??? ==4608== by 0x45947EC: ??? ==4608== by 0x40DC1D4: getgrgid_r@@GLIBC_2.1.2 (getXXbyYY_r.c:253) ==4608== by 0x804A86E: groupNameFromId (osdeps_posix.c:599) ==4608== by 0x804AA1C: osp_trustee_find (osdeps_posix.c:647) ==4608== by 0x80D0225: consdb_process_trustee (consdb_util.c:286) ==4608== by 0x80CDB1D: consdb_wctx_data (consdb2.c:356) ==4608== by 0x80D3D28: calcItemHashes (consalgo.c:603) ==4608== by 0x80D3ED3: calcSimpleGroupHashes (consalgo.c:643) ==4608== ==4608== LEAK SUMMARY: ==4608== definitely lost: 80 bytes in 2 blocks ==4608== indirectly lost: 240 bytes in 20 blocks ==4608== possibly lost: 0 bytes in 0 blocks ==4608== still reachable: 0 bytes in 0 blocks ==4608== suppressed: 0 bytes in 0 blocks ==4608== ==4608== For counts of detected and suppressed errors, rerun with: -v ==4608== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 24 from 9)
These are no leaks. This is memory which is used when the program terminates. Efforts to free the memory for valgrind are not free and especially for code like nss_compat (which shouldn't be used at all) this is too much to ask. Just ignore.
Hi, Just to say that since Ubuntu 12.04's comfiguration still uses this "compat" code, I'm still affected by this bug, hoping that anyone could fix it for me. Thanks in advance.
*** Bug 260998 has been marked as a duplicate of this bug. *** Seen from the domain http://volichat.com Page where seen: http://volichat.com/adult-chat-rooms Marked for reference. Resolved as fixed @bugzilla.