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.