public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "brooks at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org> To: glibc-bugs@sourceware.org Subject: [Bug libc/15892] New: Memory leaks in libio/* Date: Mon, 26 Aug 2013 18:01:00 -0000 [thread overview] Message-ID: <bug-15892-131@http.sourceware.org/bugzilla/> (raw) 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.
next reply other threads:[~2013-08-26 18:01 UTC|newest] Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-08-26 18:01 brooks at gcc dot gnu.org [this message] 2013-09-09 11:26 ` [Bug libc/15892] " allan at archlinux dot org 2013-09-09 12:59 ` allan at archlinux dot org 2014-06-13 13:03 ` fweimer at redhat dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-15892-131@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=glibc-bugs@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).