[Bug libc/15892] New: Memory leaks in libio/*

[Bug libc/15892] New: Memory leaks in libio/*

[brooks at gcc dot gnu.org]

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

            Bug ID: 15892
           Summary: Memory leaks in libio/*
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: brooks at gcc dot gnu.org
                CC: drepper.fsp at gmail dot com

As per Ondřej Bílka's cppcheck results, there is a memory leak in
libio/memstream.c on line 87, and libio/wmemstream.c on line 88.  This code is
the error-exit if we fail to allocate "buf":

  if (buf == NULL)
    return NULL;

This clause should free the allocated new_f before exiting; currently, it is
leaked.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-19407-listarch-glibc-bugs=sources.redhat.com@sourceware.org Mon Aug 26 18:04:18 2013
Return-Path: <glibc-bugs-return-19407-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 8474 invoked by alias); 26 Aug 2013 18:04:18 -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 8437 invoked by uid 48); 26 Aug 2013 18:04:15 -0000
From: "brooks at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug libc/15893] New: Memory leak in stdlib/isomac.c.
Date: Mon, 26 Aug 2013 18:04:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: libc
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: brooks at gcc dot gnu.org
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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter cc
Message-ID: <bug-15893-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-08/txt/msg00152.txt.bz2
Content-length: 939

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

            Bug ID: 15893
           Summary: Memory leak in stdlib/isomac.c.
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: brooks at gcc dot gnu.org
                CC: drepper.fsp at gmail dot com

As per Ondřej Bílka's cppcheck results
(http://sourceware.org/ml/libc-alpha/2013-08/msg00448.html), there is a memory
leak in stdlib/isomac.c on line 266.  This code is the error-exit if the system
call fails:

  if (system (command))
    {
      puts ("system() returned nonzero");
      return NULL;
    }

This clause should free the allocated command string before exiting; currently,
it is leaked.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-19408-listarch-glibc-bugs=sources.redhat.com@sourceware.org Mon Aug 26 18:20:47 2013
Return-Path: <glibc-bugs-return-19408-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 19754 invoked by alias); 26 Aug 2013 18:20:46 -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 19186 invoked by uid 48); 26 Aug 2013 18:20:42 -0000
From: "brooks at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug libc/15894] New: Apparent memory leak of new_environ in stdlib/setenv.c.
Date: Mon, 26 Aug 2013 18:20:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: libc
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: brooks at gcc dot gnu.org
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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter cc
Message-ID: <bug-15894-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-08/txt/msg00153.txt.bz2
Content-length: 1724

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

            Bug ID: 15894
           Summary: Apparent memory leak of new_environ in
                    stdlib/setenv.c.
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: brooks at gcc dot gnu.org
                CC: drepper.fsp at gmail dot com

As per Ondřej Bílka's cppcheck results
(http://sourceware.org/ml/libc-alpha/2013-08/msg00448.html), there is a memory
leak in stdlib/setenv.c on line 197.  This code is a conditional exit:

          if (__builtin_expect (new_environ[size] == NULL, 0))
            {
              UNLOCK;
              return -1;
            }

Here, it appears that new_environ may or may not need to be freed depending on
what happens with the realloc on line 142:

      new_environ = (char **) realloc (last_environ,
                       (size + 2) * sizeof (char *));

In particular, I note that there is different logic used for the conditional
exit on line 171:

          if (new_value == NULL)
        {
          UNLOCK;
          if (last_environ == NULL)
            free (new_environ);
          return -1;
        }

It's not clear that either of these is entirely correct; as far as I can tell,
the only way we don't leak new_environ is if (a) it happens to be the same as
last_environ due to the behavior of the realloc() call, or (b) we get to line
222, which saves it:

        last_environ = __environ = new_environ;

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-19409-listarch-glibc-bugs=sources.redhat.com@sourceware.org Mon Aug 26 18:24:16 2013
Return-Path: <glibc-bugs-return-19409-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 23452 invoked by alias); 26 Aug 2013 18:24:16 -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 23409 invoked by uid 48); 26 Aug 2013 18:24:13 -0000
From: "brooks at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug libc/15895] New: Unclosed '{' in nscd/netgroupcache.c if HAVE_SENDFILE is defined.
Date: Mon, 26 Aug 2013 18:24:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: libc
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: brooks at gcc dot gnu.org
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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter cc
Message-ID: <bug-15895-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-08/txt/msg00154.txt.bz2
Content-length: 1649

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

            Bug ID: 15895
           Summary: Unclosed '{' in nscd/netgroupcache.c if HAVE_SENDFILE
                    is defined.
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: brooks at gcc dot gnu.org
                CC: drepper.fsp at gmail dot com

As per Ondřej Bílka's cppcheck results
(http://sourceware.org/ml/libc-alpha/2013-08/msg00448.html), there is an
unclosed '{' on line 594 of nscd/netgroupcache.c if HAVE_SENDFILE is defined. 
The relevant block is:

#ifdef HAVE_SENDFILE
      if (__builtin_expect (db->mmap_used, 1) && cacheable)
    {
      assert (db->wr_fd != -1);
      assert ((char *) &dataset->resp > (char *) db->data);
      assert ((char *) dataset - (char *) db->head + sizeof (*dataset)
          <= (sizeof (struct database_pers_head)
              + db->head->module * sizeof (ref_t)
              + db->head->data_size));
# ifndef __ASSUME_SENDFILE
      ssize_t written =
# endif
        sendfileall (fd, db->wr_fd,
             (char *) &dataset->resp - (char *) db->head,
             sizeof (innetgroup_response_header));
# ifndef __ASSUME_SENDFILE
      if (written == -1 && errno == ENOSYS)
        goto use_write;
# endif
    }
      else
    {
# ifndef __ASSUME_SENDFILE
    use_write:
# endif
#endif


There is no further #ifdef HAVE_SENDFILE in that file.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-19410-listarch-glibc-bugs=sources.redhat.com@sourceware.org Mon Aug 26 20:53:42 2013
Return-Path: <glibc-bugs-return-19410-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 25929 invoked by alias); 26 Aug 2013 20:53:42 -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 25877 invoked by uid 48); 26 Aug 2013 20:53:38 -0000
From: "vincent-srcware at vinc17 dot net" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug libc/6981] __STDC_IEC_559__ should not be defined unconditionally
Date: Mon, 26 Aug 2013 20:53: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: normal
X-Bugzilla-Who: vincent-srcware at vinc17 dot net
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-6981-131-5SRwKH2MeI@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-6981-131@http.sourceware.org/bugzilla/>
References: <bug-6981-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-08/txt/msg00155.txt.bz2
Content-length: 347

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

--- Comment #2 from Vincent Lefèvre <vincent-srcware at vinc17 dot net> ---
Clang doesn't support Annex F either, even for the handling of division by
zero: http://llvm.org/bugs/show_bug.cgi?id=17000#c1

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-19411-listarch-glibc-bugs=sources.redhat.com@sourceware.org Tue Aug 27 04:46:55 2013
Return-Path: <glibc-bugs-return-19411-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 24968 invoked by alias); 27 Aug 2013 04:46:54 -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 24939 invoked by uid 48); 27 Aug 2013 04:46:51 -0000
From: "vapier at gentoo dot org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug dynamic-link/15897] New: dlopen/dlclose should not be marked as leaf functions
Date: Tue, 27 Aug 2013 04:46:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: dynamic-link
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: vapier at gentoo dot org
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: bug_id short_desc product version bug_file_loc bug_status bug_severity priority component assigned_to reporter
Message-ID: <bug-15897-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-08/txt/msg00156.txt.bz2
Content-length: 2258

https://sourceware.org/bugzilla/show_bug.cgi?id\x15897

            Bug ID: 15897
           Summary: dlopen/dlclose should not be marked as leaf functions
           Product: glibc
           Version: unspecified
               URL: https://sourceware.org/ml/libc-help/2013-07/msg00015.h
                    tml
            Status: NEW
          Severity: normal
          Priority: P2
         Component: dynamic-link
          Assignee: unassigned at sourceware dot org
          Reporter: vapier at gentoo dot org

as reported by Fabrice Bauzac:

I might have found a bug in glibc.

On my Ubuntu64 server I have glibc 2.17 (see attached libc.version)
and gcc 4.7.3.

In dlfcn.h I have this definition of dlopen():
/* Open the shared object FILE and map it in; return a handle that can be
   passed to `dlsym' to get symbol values from it.  */
extern void *dlopen (const char *__file, int __mode) __THROW;

I have a small test case with a static variable and a call to dlopen()
or a similar function: see attached main.c.

When I compile with the given Makefile
cc -O2 -Wall -Wextra -save-temps -S -o main.s main.c
the generated assembly code (attached main.s) does not contain the
assignment "var=3;" anymore.  I think it is a bug: the assignment
"var=3" should be done, because in the .so if there are constructors
(functions called at dlopen() time) they might use "var" indirectly
via the function increase_var().  And that's what is currently
happening to me (in a more complex case): I have a constructor that
actually needs some "var" to be set to 3.

Now why is this assignment removed by the compiler?

If in call_external_function() I call my_external_function() instead
of dlopen(), the problem remains, except if I remove the __THROW
attribute in which case "var" is assigned 3, then the funcall is done,
then "var" is assigned to 0.

According to cc -O2 -save-temps file.c (look at the generated .i),
__THROW means:
__attribute__((nothrow, leaf))

Maybe it is the "leaf" attribute that allows gcc to remove the
"var=3;" assignment?  See
http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html

Maybe dlopen() should not be marked as "leaf".  What do you think?

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

[Bug libc/15892] Memory leaks in libio/*

[allan at archlinux dot org]

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

Allan McRae <allan at archlinux dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |allan at archlinux dot org
           Assignee|unassigned at sourceware dot org   |allan at archlinux dot org

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

[Bug libc/15892] Memory leaks in libio/*

[allan at archlinux dot org]

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

Allan McRae <allan at archlinux dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #1 from Allan McRae <allan at archlinux dot org> ---
commit 3932737df1a022f8f207db9874194600296ed437
Author: Allan McRae <allan@archlinux.org>
Date:   Mon Sep 9 22:50:41 2013 +1000

    Fix memory leaks in libio on allocation failure

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

[Bug libc/15892] Memory leaks in libio/*

[fweimer at redhat dot com]

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

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fweimer at redhat dot com
              Flags|                            |security-

--- Comment #2 from Florian Weimer <fweimer at redhat dot com> ---
I don't think we have to treat this as a denial-of-service issues because it
happens only after a memory allocation failure.

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