[Bug libstdc++/65434] New: Memory leak in pool constructor

[Bug libstdc++/65434] New: Memory leak in pool constructor

[mitya57 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65434

            Bug ID: 65434
           Summary: Memory leak in pool constructor
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: mitya57 at gmail dot com

Constructor of `pool' class in eh_alloc.c has the following code:

pool::pool()
  {
    // Allocate the arena - we could add a GLIBCXX_EH_ARENA_SIZE environment
    // to make this tunable.
    arena_size = (EMERGENCY_OBJ_SIZE * EMERGENCY_OBJ_COUNT
                  + EMERGENCY_OBJ_COUNT * sizeof (__cxa_dependent_exception));
    arena = (char *)malloc (arena_size);
    ....
  }

The memory allocated by `malloc (arena_size)' is never freed, because that
class does not have a destructor. This results in a memory leak. Valgrind
reports:

18,944 bytes in 1 blocks are still reachable in loss record 1 of 1
   at 0x40291CC: malloc (vg_replace_malloc.c:296)
   by 0x40D630A: pool (eh_alloc.cc:117)
   by 0x40D630A: __static_initialization_and_destruction_0 (eh_alloc.cc:244)
   by 0x40D630A: _GLOBAL__sub_I_eh_alloc.cc (eh_alloc.cc:307)
   by 0x400E86D: call_init.part.0 (dl-init.c:78)
   by 0x400E963: call_init (dl-init.c:36)
   by 0x400E963: _dl_init (dl-init.c:126)
   by 0x4000D3E: ??? (in /lib/i386-linux-gnu/ld-2.19.so)

This happens with the current gcc-5 snapshot, but did not happen with 4.9.

It was broken in revision 219988 (PR libstdc++/64535).

[Bug libstdc++/65434] Memory leak in pool constructor

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65434

Jonathan Wakely <redi at gcc dot gnu.org> changed:

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

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Dmitry Shachnev from comment #0)
> 18,944 bytes in 1 blocks are still reachable in loss record 1 of 1

"still reachable" is not a leak, the memory is still in use by the runtime.

This is intentional.

[Bug libstdc++/65434] Memory leak in pool constructor

[mitya57 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65434

--- Comment #2 from Dmitry Shachnev <mitya57 at gmail dot com> ---
Will anything bad happen if that memory is freed in the destructor?

For me, the issue is mostly aesthetic — I got used to not seeing any Valgrind
warnings in my programs :)
>From gcc-bugs-return-480468-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Mar 16 15:42:51 2015
Return-Path: <gcc-bugs-return-480468-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 3125 invoked by alias); 16 Mar 2015 15:42:51 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 3063 invoked by uid 48); 16 Mar 2015 15:42:48 -0000
From: "mpolacek at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/37303] const compound initializers in structs are written to .data instead of .rodata
Date: Mon, 16 Mar 2015 15:42:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: 4.3.2
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: mpolacek at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status cc resolution
Message-ID: <bug-37303-4-0Jfki5fNif@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-37303-4@http.gcc.gnu.org/bugzilla/>
References: <bug-37303-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-03/txt/msg01612.txt.bz2
Content-length: 524

https://gcc.gnu.org/bugzilla/show_bug.cgi?id7303

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |mpolacek at gcc dot gnu.org
         Resolution|---                         |FIXED

--- Comment #9 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
This one should be fixed.

[Bug libstdc++/65434] Memory leak in pool constructor

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65434

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Dmitry Shachnev from comment #2)
> Will anything bad happen if that memory is freed in the destructor?

Yes, because other destructors could run later, and could (potentially) need to
use the pool after it had been destroyed. That would be undefined behaviour.

> For me, the issue is mostly aesthetic — I got used to not seeing any
> Valgrind warnings in my programs :)

Then add a valgrind suppression, or ask upstream valgrind to add it.
>From gcc-bugs-return-480476-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Mar 16 16:10:53 2015
Return-Path: <gcc-bugs-return-480476-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 115734 invoked by alias); 16 Mar 2015 16:10:53 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 115674 invoked by uid 55); 16 Mar 2015 16:10:49 -0000
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/65431] [5 Regression] Invalid read of size 8 at 0x105DBBF8: delete_omp_context(unsigned long) (omp-low.c:1586)
Date: Mon, 16 Mar 2015 16:10:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: jakub at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-65431-4-W8xt3XsYx9@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65431-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65431-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-03/txt/msg01620.txt.bz2
Content-length: 519

https://gcc.gnu.org/bugzilla/show_bug.cgi?ide431

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Author: jakub
Date: Mon Mar 16 16:10:17 2015
New Revision: 221459

URL: https://gcc.gnu.org/viewcvs?rev"1459&root=gcc&view=rev
Log:
    PR middle-end/65431
    * omp-low.c (delete_omp_context): Only splay_tree_delete
    reduction_map in GIMPLE_OMP_TARGET is_gimple_omp_offloaded
    is_gimple_omp_oacc contexts.  Don't look at ctx->outer.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/omp-low.c