Bug 2314 - nss_parse_service_list leaks a tiny amount of memory
Summary: nss_parse_service_list leaks a tiny amount of memory
Status: RESOLVED WONTFIX
Alias: None
Product: glibc
Classification: Unclassified
Component: libc (show other bugs)
Version: 2.3.6
: P2 minor
Target Milestone: ---
Assignee: Ulrich Drepper
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-02-09 20:04 UTC by David
Modified: 2014-05-28 19:46 UTC (History)
5 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments
Test file showing memory leak (326 bytes, text/plain)
2007-02-04 06:12 UTC, John Darrington
Details

Note You need to log in before you can comment on or make changes to this bug.
Description David 2006-02-09 20:04:13 UTC
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)
Comment 1 Ulrich Drepper 2006-02-09 20:16:56 UTC
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.
Comment 2 David 2006-02-09 20:35:44 UTC
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 :) 
Comment 3 John Darrington 2007-02-04 06:12:04 UTC
Created attachment 1535 [details]
Test file showing memory leak

getpwnam_r calls  nss_parse_service_list  which allocates memory which it
doesn't free.
Comment 4 John Darrington 2007-02-04 06:16:12 UTC
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.
Comment 5 Ulrich Drepper 2007-02-16 06:51:34 UTC
libc frees the memory already.  I cannot see anything wrong.  You'll have to
provide a test case.  In source form.
Comment 6 Ulrich Drepper 2007-08-23 18:30:31 UTC
No reply in 6+ months.  Closing.
Comment 7 Andreas Köhler 2010-08-08 15:20:58 UTC
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().
Comment 8 Maxim Zinal 2012-02-01 08:37:53 UTC
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)
Comment 9 Ulrich Drepper 2012-02-03 20:58:24 UTC
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.
Comment 10 林博仁 2013-06-20 13:27:02 UTC
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.
Comment 11 Jackie Rosen 2014-02-16 19:41:28 UTC Comment hidden (spam)