[Bug libc/2314] nss_parse_service_list leaks a tiny amount of memory

[Bug libc/2314] nss_parse_service_list leaks a tiny amount of memory

[james.m.henderson at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=2314

James Henderson <james.m.henderson at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |james.m.henderson at gmail
                   |                            |dot com

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/2314] nss_parse_service_list leaks a tiny amount of memory

[MaxZinal at yandex dot ru]

http://sourceware.org/bugzilla/show_bug.cgi?id=2314

Maxim Zinal <MaxZinal at yandex dot ru> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |MaxZinal at yandex dot ru

--- Comment #8 from Maxim Zinal <MaxZinal at yandex dot ru> 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)

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/2314] nss_parse_service_list leaks a tiny amount of memory

[drepper.fsp at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=2314

Ulrich Drepper <drepper.fsp at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |WONTFIX

--- Comment #9 from Ulrich Drepper <drepper.fsp at gmail dot com> 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.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/2314] nss_parse_service_list leaks a tiny amount of memory

[pika1021 at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=2314

林博仁 <pika1021 at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pika1021 at gmail dot com

--- Comment #10 from 林博仁 <pika1021 at gmail dot com> ---
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-18987-listarch-glibc-bugs=sources.redhat.com@sourceware.org Thu Jun 20 13:51:48 2013
Return-Path: <glibc-bugs-return-18987-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 9802 invoked by alias); 20 Jun 2013 13:51:48 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 9756 invoked by uid 48); 20 Jun 2013 13:51:43 -0000
From: "carlos at redhat dot com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug libc/15648] multiple definition of `__lll_lock_wait_private'
Date: Thu, 20 Jun 2013 13:51:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: libc
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: carlos at redhat dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-15648-131-qSidJbCReh@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-15648-131@http.sourceware.org/bugzilla/>
References: <bug-15648-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-06/txt/msg00166.txt.bz2
Content-length: 647

http://sourceware.org/bugzilla/show_bug.cgi?id\x15648

--- Comment #12 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Jakub Jelinek from comment #11)
> (In reply to Neil from comment #8)
> > If ld include libc-lowlevellock.o first, it always cause error when
> > includeing lowlevellock.o. Right?
>
> But why does that happen?
> You link -lc before -lpthread?  That is never going to work properly when
> linking the libraries statically.

A `gcc -v...` would help show what's going on here.

Neil, can you give us the verbose output of the compile?

--
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/2314] nss_parse_service_list leaks a tiny amount of memory

[jackie.rosen at hushmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=2314

Jackie Rosen <jackie.rosen at hushmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jackie.rosen at hushmail dot com

--- Comment #11 from Jackie Rosen <jackie.rosen at hushmail dot com> ---
*** 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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/2314] nss_parse_service_list leaks a tiny amount of memory

[schwab at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=2314

Andreas Schwab <schwab at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|jackie.rosen at hushmail dot com   |

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/2314] New: nss_parse_service_list leaks a tiny amount of memory

[david at edeca dot net]

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)

-- 
           Summary: nss_parse_service_list leaks a tiny amount of memory
           Product: glibc
           Version: 2.3.6
            Status: NEW
          Severity: minor
          Priority: P2
         Component: libc
        AssignedTo: drepper at redhat dot com
        ReportedBy: david at edeca dot net
                CC: glibc-bugs at sources dot redhat dot com


http://sourceware.org/bugzilla/show_bug.cgi?id=2314

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/2314] nss_parse_service_list leaks a tiny amount of memory

[drepper at redhat dot com]

------- Additional Comments From drepper at redhat dot com  2006-02-09 20:16 -------
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.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING


http://sourceware.org/bugzilla/show_bug.cgi?id=2314

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/2314] nss_parse_service_list leaks a tiny amount of memory

[david at edeca dot net]

------- Additional Comments From david at edeca dot net  2006-02-09 20:35 -------
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 :) 

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|                            |INVALID


http://sourceware.org/bugzilla/show_bug.cgi?id=2314

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/2314] nss_parse_service_list leaks a tiny amount of memory

[john at cellform dot com]

------- Additional Comments From john at cellform dot com  2007-02-04 06:12 -------
Created an attachment (id=1535)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=1535&action=view)
Test file showing memory leak

getpwnam_r calls  nss_parse_service_list  which allocates memory which it
doesn't free.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=2314

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/2314] nss_parse_service_list leaks a tiny amount of memory

[john at cellform dot com]

------- Additional Comments From john at cellform dot com  2007-02-04 06:16 -------
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.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |


http://sourceware.org/bugzilla/show_bug.cgi?id=2314

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/2314] nss_parse_service_list leaks a tiny amount of memory

[drepper at redhat dot com]

------- Additional Comments From drepper at redhat dot com  2007-02-16 06:51 -------
libc frees the memory already.  I cannot see anything wrong.  You'll have to
provide a test case.  In source form.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |WAITING


http://sourceware.org/bugzilla/show_bug.cgi?id=2314

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/2314] nss_parse_service_list leaks a tiny amount of memory

[drepper at redhat dot com]

------- Additional Comments From drepper at redhat dot com  2007-08-23 18:30 -------
No reply in 6+ months.  Closing.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|                            |WORKSFORME


http://sourceware.org/bugzilla/show_bug.cgi?id=2314

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/2314] nss_parse_service_list leaks a tiny amount of memory

[andi5 dot py at gmx dot net]

------- Additional Comments From andi5 dot py at gmx dot net  2010-08-08 15:20 -------
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().


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WORKSFORME                  |


http://sourceware.org/bugzilla/show_bug.cgi?id=2314

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/2314] nss_parse_service_list leaks a tiny amount of memory

[andi5 dot py at gmx dot net]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andi5 dot py at gmx dot net


http://sourceware.org/bugzilla/show_bug.cgi?id=2314

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.