From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7180 invoked by alias); 26 Aug 2013 18:01:25 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Received: (qmail 7134 invoked by uid 48); 26 Aug 2013 18:01:21 -0000 From: "brooks at gcc dot gnu.org" To: glibc-bugs@sourceware.org Subject: [Bug libc/15892] New: Memory leaks in libio/* Date: Mon, 26 Aug 2013 18:01: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: 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/msg00151.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=3D15892 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=C5=99ej B=C3=ADlka'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 =3D=3D NULL) return NULL; This clause should free the allocated new_f before exiting; currently, it is leaked. --=20 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: 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: List-Subscribe: List-Post: List-Help: , 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" 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: 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=3D15893 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=C5=99ej B=C3=ADlka's cppcheck results (http://sourceware.org/ml/libc-alpha/2013-08/msg00448.html), there is a mem= ory leak in stdlib/isomac.c on line 266. This code is the error-exit if the sy= stem call fails: if (system (command)) { puts ("system() returned nonzero"); return NULL; } This clause should free the allocated command string before exiting; curren= tly, it is leaked. --=20 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: 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: List-Subscribe: List-Post: List-Help: , 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" 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: 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=3D15894 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=C5=99ej B=C3=ADlka's cppcheck results (http://sourceware.org/ml/libc-alpha/2013-08/msg00448.html), there is a mem= ory leak in stdlib/setenv.c on line 197. This code is a conditional exit: if (__builtin_expect (new_environ[size] =3D=3D 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 =3D (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 =3D=3D NULL) { UNLOCK; if (last_environ =3D=3D NULL) free (new_environ); return -1; } It's not clear that either of these is entirely correct; as far as I can te= ll, 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 li= ne 222, which saves it: last_environ =3D __environ =3D new_environ; --=20 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: 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: List-Subscribe: List-Post: List-Help: , 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" 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: 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=3D15895 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=C5=99ej B=C3=ADlka'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 define= d.=20 The relevant block is: #ifdef HAVE_SENDFILE if (__builtin_expect (db->mmap_used, 1) && cacheable) { assert (db->wr_fd !=3D -1); assert ((char *) &dataset->resp > (char *) db->data); assert ((char *) dataset - (char *) db->head + sizeof (*dataset) <=3D (sizeof (struct database_pers_head) + db->head->module * sizeof (ref_t) + db->head->data_size)); # ifndef __ASSUME_SENDFILE ssize_t written =3D # endif sendfileall (fd, db->wr_fd, (char *) &dataset->resp - (char *) db->head, sizeof (innetgroup_response_header)); # ifndef __ASSUME_SENDFILE if (written =3D=3D -1 && errno =3D=3D ENOSYS) goto use_write; # endif } else { # ifndef __ASSUME_SENDFILE use_write: # endif #endif There is no further #ifdef HAVE_SENDFILE in that file. --=20 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: 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: List-Subscribe: List-Post: List-Help: , 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" 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: In-Reply-To: References: 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=3D6981 --- Comment #2 from Vincent Lef=C3=A8vre --- Clang doesn't support Annex F either, even for the handling of division by zero: http://llvm.org/bugs/show_bug.cgi?id=3D17000#c1 --=20 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: 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: List-Subscribe: List-Post: List-Help: , 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" 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: 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=15897 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.