[Bug fortran/60922] New: [4.9 regression] Memory leak with INTENT(OUT) CLASS argument w/ allocatable CLASS components

[Bug fortran/60922] New: [4.9 regression] Memory leak with INTENT(OUT) CLASS argument w/ allocatable CLASS components

[sfilippone at uniroma2 dot it]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60922

            Bug ID: 60922
           Summary: [4.9 regression]  Memory leak with INTENT(OUT) CLASS
                    argument w/ allocatable CLASS components
           Product: gcc
           Version: 4.10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: sfilippone at uniroma2 dot it

Created attachment 32653
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32653&action=edit
test case

Attached code runs fine with 4.8.2, but generates a memory leak with current
trunk, unless I explicitly add FINAL subroutines, which should not be necessary
for this simple case. Possibly 4.9.0 is affected as well. 
Symptoms similar to PR 47637. 
------------ fails with trunk -------------------
[sfilippo@epsilon IMAGING]$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/opt/gnu/4.9/libexec/gcc/x86_64-unknown-linux-gnu/4.10.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure --prefix=/opt/gnu/4.9
--enable-languages=c,c++,fortran --with-gmp=/usr/local/travel/GNU/gmp
--with-mpfr=/usr/local/travel/GNU/mpfr --with-mpc=/usr/local/travel/GNU/mpc
--with-cloog=/usr/local/travel/GNU/cloog : (reconfigured) ../gcc/configure
--prefix=/opt/gnu/4.9 --with-gmp=/usr/local/travel/GNU/gmp
--with-mpfr=/usr/local/travel/GNU/mpfr --with-mpc=/usr/local/travel/GNU/mpc
--with-cloog=/usr/local/travel/GNU/cloog --enable-languages=c,c++,fortran,lto
--no-create --no-recursion
Thread model: posix
gcc version 4.10.0 20140422 (experimental) (GCC) 
[sfilippo@epsilon IMAGING]$ gfortran -o test_leak_410 -O3 test_leak.f90
[sfilippo@epsilon IMAGING]$ valgrind ./test_leak_410
==2140== Memcheck, a memory error detector
==2140== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==2140== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==2140== Command: ./test_leak_410
==2140== 
 Iteration            1
 Iteration            2
==2140== 
==2140== HEAP SUMMARY:
==2140==     in use at exit: 6,291,552 bytes in 5 blocks
==2140==   total heap usage: 32 allocs, 27 frees, 10,497,741 bytes allocated
==2140== 
==2140== LEAK SUMMARY:
==2140==    definitely lost: 48 bytes in 1 blocks
==2140==    indirectly lost: 2,097,152 bytes in 1 blocks
==2140==      possibly lost: 0 bytes in 0 blocks
==2140==    still reachable: 4,194,352 bytes in 3 blocks
==2140==         suppressed: 0 bytes in 0 blocks
==2140== Rerun with --leak-check=full to see details of leaked memory
==2140== 
==2140== For counts of detected and suppressed errors, rerun with: -v
==2140== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 6 from 6)



--------Works with 4.8.2-----------
[sfilippo@epsilon IMAGING]$ gfortran -v 
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/opt/gnu/4.8.2/libexec/gcc/x86_64-unknown-linux-gnu/4.8.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.8.2/configure --prefix=/opt/gnu/4.8.2
--enable-languages=c,c++,fortran --with-gmp=/usr/local/travel/GNU/gmp
--with-mpfr=/usr/local/travel/GNU/mpfr --with-mpc=/usr/local/travel/GNU/mpc
--with-cloog=/usr/local/travel/GNU/cloog
Thread model: posix
gcc version 4.8.2 (GCC) 
[sfilippo@epsilon IMAGING]$ gfortran -o test_leak_482 -O3 test_leak.f90
[sfilippo@epsilon IMAGING]$ valgrind ./test_leak_482
==2122== Memcheck, a memory error detector
==2122== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==2122== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==2122== Command: ./test_leak_482
==2122== 
 Iteration            1
 Iteration            2
==2122== 
==2122== HEAP SUMMARY:
==2122==     in use at exit: 4,194,352 bytes in 3 blocks
==2122==   total heap usage: 28 allocs, 25 frees, 10,497,699 bytes allocated
==2122== 
==2122== LEAK SUMMARY:
==2122==    definitely lost: 0 bytes in 0 blocks
==2122==    indirectly lost: 0 bytes in 0 blocks
==2122==      possibly lost: 0 bytes in 0 blocks
==2122==    still reachable: 4,194,352 bytes in 3 blocks
==2122==         suppressed: 0 bytes in 0 blocks
==2122== Rerun with --leak-check=full to see details of leaked memory
==2122== 
==2122== For counts of detected and suppressed errors, rerun with: -v
==2122== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 6 from 6)

[Bug fortran/60922] [4.9/4.10 regression] Memory leak with INTENT(OUT) CLASS argument w/ allocatable CLASS components

[sfilippone at uniroma2 dot it]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60922

Salvatore Filippone <sfilippone at uniroma2 dot it> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[4.10 regression]  Memory   |[4.9/4.10 regression]
                   |leak with INTENT(OUT) CLASS |Memory leak with
                   |argument w/ allocatable     |INTENT(OUT) CLASS argument
                   |CLASS components            |w/ allocatable CLASS
                   |                            |components

--- Comment #1 from Salvatore Filippone <sfilippone at uniroma2 dot it> ---
Yup, it is a regression in 4.9.0 as well. 
[sfilippo@epsilon IMAGING]$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/opt/gnu/4.9.0/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.9.0/configure --prefix=/opt/gnu/4.9.0
--enable-languages=c,c++,fortran --with-gmp=/usr/local/travel/GNU/gmp
--with-mpfr=/usr/local/travel/GNU/mpfr --with-mpc=/usr/local/travel/GNU/mpc
--with-cloog=/usr/local/travel/GNU/cloog
Thread model: posix
gcc version 4.9.0 (GCC) 
[sfilippo@epsilon IMAGING]$ gfortran -o test_leak_490 -O3 test_leak.f90 
[sfilippo@epsilon IMAGING]$ valgrind ./test_leak_490
==4473== Memcheck, a memory error detector
==4473== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==4473== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==4473== Command: ./test_leak_490
==4473== 
 Iteration            1
 Iteration            2
==4473== 
==4473== HEAP SUMMARY:
==4473==     in use at exit: 6,291,552 bytes in 5 blocks
==4473==   total heap usage: 32 allocs, 27 frees, 10,497,741 bytes allocated
==4473== 
==4473== LEAK SUMMARY:
==4473==    definitely lost: 48 bytes in 1 blocks
==4473==    indirectly lost: 2,097,152 bytes in 1 blocks
==4473==      possibly lost: 0 bytes in 0 blocks
==4473==    still reachable: 4,194,352 bytes in 3 blocks
==4473==         suppressed: 0 bytes in 0 blocks
==4473== Rerun with --leak-check=full to see details of leaked memory
==4473== 
==4473== For counts of detected and suppressed errors, rerun with: -v
==4473== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 6 from 6)

[Bug fortran/60922] [4.9/4.10 regression] Memory leak with INTENT(OUT) CLASS argument w/ allocatable CLASS components

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60922

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
           Priority|P3                          |P4
   Target Milestone|---                         |4.9.1

[Bug fortran/60922] [4.9/4.10 regression] Memory leak with INTENT(OUT) CLASS argument w/ allocatable CLASS components

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60922

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2014-04-27
     Ever confirmed|0                           |1

--- Comment #2 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
On x86_64-apple-darwin* I see the memory leak for all the revisions I have
tested from 4.5 to trunk. For 4.8.2 on x86_64-apple-darwin10 valgrind reports;

 Iteration            1
==16277== Conditional jump or move depends on uninitialised value(s)
==16277==    at 0x1000012FF: __d_vect_mod_MOD_d_vect_bld_x (pr60922.f90:118)
==16277==    by 0x100001A33: MAIN__ (pr60922.f90:155)
==16277==    by 0x100001A7D: main (pr60922.f90:127)
==16277==  Uninitialised value was created by a stack allocation
==16277==    at 0x100001115: __d_vect_mod_MOD_d_vect_bld_x (pr60922.f90:111)
==16277== 
==16277== Conditional jump or move depends on uninitialised value(s)
==16277==    at 0x100001309: __d_vect_mod_MOD_d_vect_bld_x (pr60922.f90:118)
==16277==    by 0x100001A33: MAIN__ (pr60922.f90:155)
==16277==    by 0x100001A7D: main (pr60922.f90:127)
==16277==  Uninitialised value was created by a stack allocation
==16277==    at 0x100001115: __d_vect_mod_MOD_d_vect_bld_x (pr60922.f90:111)
==16277== 
 Iteration            2
==16277== 
==16277== HEAP SUMMARY:
==16277==     in use at exit: 2,097,288 bytes in 3 blocks
==16277==   total heap usage: 22 allocs, 19 frees, 6,295,373 bytes allocated
==16277== 
==16277== 48 bytes in 1 blocks are still reachable in loss record 1 of 3
==16277==    at 0x100014679: malloc (vg_replace_malloc.c:266)
==16277==    by 0x10000124D: __d_vect_mod_MOD_d_vect_bld_x (pr60922.f90:116)
==16277==    by 0x100001A33: MAIN__ (pr60922.f90:155)
==16277==    by 0x100001A7D: main (pr60922.f90:127)
==16277== 
==16277== 2,097,152 bytes in 1 blocks are still reachable in loss record 3 of 3
==16277==    at 0x100014679: malloc (vg_replace_malloc.c:266)
==16277==    by 0x1000016FB: __d_vect_mod_MOD_array_bld (pr60922.f90:85)
==16277==    by 0x100001A0A: MAIN__ (pr60922.f90:145)
==16277==    by 0x100001A7D: main (pr60922.f90:127)
==16277== 
==16277== LEAK SUMMARY:
==16277==    definitely lost: 0 bytes in 0 blocks
==16277==    indirectly lost: 0 bytes in 0 blocks
==16277==      possibly lost: 0 bytes in 0 blocks
==16277==    still reachable: 2,097,200 bytes in 2 blocks
==16277==         suppressed: 88 bytes in 1 blocks
==16277== 
==16277== For counts of detected and suppressed errors, rerun with: -v
==16277== ERROR SUMMARY: 4 errors from 2 contexts (suppressed: 0 from 0)

[Bug fortran/60922] [4.9/4.10 regression] Memory leak with INTENT(OUT) CLASS argument w/ allocatable CLASS components

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.9.1                       |4.9.2

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.9.1 has been released.

[Bug fortran/60922] [4.9/4.10 regression] Memory leak with INTENT(OUT) CLASS argument w/ allocatable CLASS components

[sfilippone at uniroma2 dot it]

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

--- Comment #4 from Salvatore Filippone <sfilippone at uniroma2 dot it> ---
Looking at the original code of PR 61819, it is quite possible that the real
culprit are CLASS() ALLOCATABLE components, not necessarily the result itself
(being allocatable).
Salvatore

[Bug fortran/60922] [4.9/5 regression] Memory leak with INTENT(OUT) CLASS argument w/ allocatable CLASS components

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.9.2                       |4.9.3

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.9.2 has been released.

[Bug fortran/60922] [4.9/5 regression] Memory leak with INTENT(OUT) CLASS argument w/ allocatable CLASS components

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

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

--- Comment #6 from janus at gcc dot gnu.org ---
Here is a reduced and cleaned-up test case:


program test_leak
  implicit none

  type d_base_vect_type
  end type

  type d_vect_type
    class(d_base_vect_type), allocatable :: v
  end type

  type(d_vect_type) :: ainvd
  integer :: itx

  do itx=1,2
    write(*,*) 'Iteration ',itx
    call d_vect_bld_x(ainvd)
  end do

contains

  subroutine d_vect_bld_x(x)
    class(d_vect_type), intent(out) :: x
    allocate(x%v)
  end subroutine

end program


With 4.9 and trunk (but not with 4.8), valgrind shows:

==11044== 1 bytes in 1 blocks are definitely lost in loss record 2 of 2
==11044==    at 0x4C2ABA0: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==11044==    by 0x40102F: d_vect_bld_x.3431 (test_leak.f90:23)
==11044==    by 0x400EA3: MAIN__ (test_leak.f90:16)
==11044==    by 0x401096: main (test_leak.f90:14)

[Bug fortran/60922] [4.9/5 regression] Memory leak with INTENT(OUT) CLASS argument w/ allocatable CLASS components

[janus at gcc dot gnu.org]

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

--- Comment #7 from janus at gcc dot gnu.org ---
Looking at the output of -fdump-tree-original for comment 6, one sees with 4.8:

d_vect_bld_x (struct __class_test_leak_D_vect_type & restrict x)
{
  if (x->_data->v._data != 0B)
    {
      __builtin_free ((void *) x->_data->v._data);
    }

while trunk shows:

d_vect_bld_x (struct __class_test_leak_D_vect_type_t & restrict x)
{
  if (x->_vptr->_final != 0B)
    {
      {
        struct array0_d_vect_type desc.7;

        desc.7.dtype = 1064;
        desc.7.data = (void * restrict) x->_data;
        x->_vptr->_final (&desc.7, x->_vptr->_size, 0);
      }
    }


That is: In 4.8 the argument x is directly freed when entering the function. On
trunk (after the implementation of finalization) the _final routine is called
instead. Apparently the latter fails to properly free the allocatable class
component.

[Bug fortran/60922] [4.9/5 regression] Memory leak with allocatable CLASS components

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[4.9/5 regression]  Memory  |[4.9/5 regression] Memory
                   |leak with INTENT(OUT) CLASS |leak with allocatable CLASS
                   |argument w/ allocatable     |components
                   |CLASS components            |

--- Comment #8 from janus at gcc dot gnu.org ---
As comment 7 shows, the problem is not specific to intent(out) arguments but
can occur also in other contexts where deallocation/finalization should occur.

The following test case demonstrates the same leak with an auto-deallocated
local variable (again leaks with 4.9 and trunk, but not 4.8):


program test_leak
  implicit none

  type d_base_vect_type
  end type

  type d_vect_type
    class(d_base_vect_type), allocatable :: v
  end type

  call test()

contains

  subroutine test()
    class(d_vect_type), allocatable :: x
    allocate(x)
    allocate(x%v)
    print *,"allocated!"
  end subroutine

end

[Bug fortran/60922] [4.9/5 regression] Memory leak with allocatable CLASS components

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu.org

--- Comment #9 from janus at gcc dot gnu.org ---
Looking at the dump of the finalizer function (__final_test_leak_D_vect_type)
shows that it indeed has code to free the component v:


if (fini_coarray)
  {
    {
      integer(kind=4) stat.5;

      if (ptr->v._data == 0B)
    {
      stat.5 = 1;
    }
      else
    {
      if (ptr->v._vptr->_final != 0B)
        {
          {
        struct array0_d_base_vect_type desc.6;

        desc.6.dtype = 40;
        desc.6.data = (void * restrict) ptr->v._data;
        ptr->v._vptr->_final (&desc.6, ptr->v._vptr->_size, 0);
          }
        }
      __builtin_free ((void *) ptr->v._data);
      stat.5 = 0;
    }


However, it is guarded by the check for 'fini_coarray', which is the third
argument of the finalizer function and is being set to zero on invocation:

                x._vptr->_final (&desc.8, x._vptr->_size, 0);

The documentation of 'generate_finalization_wrapper' in class.c says:

If "fini_coarray" is false, coarray components are not finalized to allow for
the correct semantic with intrinsic assignment.

So I guess it should only apply to COARRAY components, not to CLASS components.

Tobias: I guess you were the one who implemented it. Could you please comment
on this?

[Bug fortran/60922] [4.9/5 regression] Memory leak with allocatable CLASS components

[janus at gcc dot gnu.org]

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

--- Comment #11 from janus at gcc dot gnu.org ---
(In reply to janus from comment #10)
> The following patchlet seems to fix it. Might just be a copy'n'paste error?

In any case it regtests cleanly.

[Bug fortran/60922] [4.9/5 Regression] Memory leak with allocatable CLASS components

[janus at gcc dot gnu.org]

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

--- Comment #12 from janus at gcc dot gnu.org ---
Author: janus
Date: Fri Jan 23 08:32:09 2015
New Revision: 220029

URL: https://gcc.gnu.org/viewcvs?rev=220029&root=gcc&view=rev
Log:
2015-01-23  Janus Weil  <janus@gcc.gnu.org>

    PR fortran/60922
    * class.c (finalize_component): Apply the check for 'fini_coarray' only
    to coarray components.

2015-01-23  Janus Weil  <janus@gcc.gnu.org>

    PR fortran/60922
    * gfortran.dg/class_allocate_17.f90: New.

Added:
    trunk/gcc/testsuite/gfortran.dg/class_allocate_17.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/class.c
    trunk/gcc/testsuite/ChangeLog

[Bug fortran/60922] [4.9/5 Regression] Memory leak with allocatable CLASS components

[janus at gcc dot gnu.org]

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

--- Comment #13 from janus at gcc dot gnu.org ---
Author: janus
Date: Sat Jan 24 10:11:52 2015
New Revision: 220078

URL: https://gcc.gnu.org/viewcvs?rev=220078&root=gcc&view=rev
Log:
2015-01-24  Janus Weil  <janus@gcc.gnu.org>

    Backport from mainline
    PR fortran/60922
    * class.c (finalize_component): Apply the check for 'fini_coarray' only
    to coarray components.

2015-01-24  Janus Weil  <janus@gcc.gnu.org>

    Backport from mainline
    PR fortran/60922
    * gfortran.dg/class_allocate_17.f90: New.

Added:
    branches/gcc-4_9-branch/gcc/testsuite/gfortran.dg/class_allocate_17.f90
Modified:
    branches/gcc-4_9-branch/gcc/fortran/ChangeLog
    branches/gcc-4_9-branch/gcc/fortran/class.c
    branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug fortran/60922] [4.9/5 Regression] Memory leak with allocatable CLASS components

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

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

--- Comment #14 from janus at gcc dot gnu.org ---
Fixed on trunk and 4.9. Closing.

Thanks for the report!