[Bug fortran/32795] New: Leaking memory (generated prog) with type constructor & allocatable components

[Bug fortran/32795] New: Leaking memory (generated prog) with type constructor & allocatable components

[burnus at gcc dot gnu dot org]

Taken from my remark to PR31320,
http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01457.html

The generated executable leaks memory:

 96 bytes in 1 blocks are definitely lost in loss record 1 of 2
    at 0x4C22D06: malloc (in
/usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
    by 0x40122B: MAIN__ (alloc_comp_assign_2.f90:11)
    by 0x401EEB: main (fmain.c:22)

 96 bytes in 1 blocks are definitely lost in loss record 2 of 2
    at 0x4C22D06: malloc (in
/usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
    by 0x400BCA: MAIN__ (alloc_comp_assign_2.f90:10)
    by 0x401EEB: main (fmain.c:22)


for this stripped down test case

  type :: a
    integer, allocatable :: i(:)
  end type a
  type :: b
    type (a), allocatable :: at(:)
  end type b
  type(a) :: x(2)
  type(b) :: y(2)
  integer i
  y(1) = b ((/x(1),x(2)/))
  y(2) = b ((/x(2),x(1)/))
  forall (i=1:2) y(i) = b ((/x(i)/))
end

Paul remarked:
The testcase that you sent me breaks gfortran in other places and probably
should have a PR all of its very own.  (try the FORALL part separately).


-- 
           Summary: Leaking memory (generated prog) with type constructor &
                    allocatable components
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Keywords: wrong-code
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: burnus at gcc dot gnu dot org


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

[Bug fortran/32795] Leaking memory (generated prog) with type constructor & allocatable components

[dfranke at gcc dot gnu dot org]

------- Comment #1 from dfranke at gcc dot gnu dot org  2007-07-17 21:42 -------
After update to r126703, updated example from pr31320, comment #4:

  type :: a
    integer, allocatable :: i(:)
  end type a
  type(a) :: x, y

  x = a ((/ 1,2,3 /))
! y = a (x%i(1:3))       ! ok
! y = a (x%i(1:))        ! ok
! y = a (x%i(:3))        ! ok
! y = a (x%i(:))         ! memory leak
! y = a (x%i)            ! memory leak
! y = x                  ! ok
end

==21521== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 7 from 1)
==21521== malloc/free: in use at exit: 12 bytes in 1 blocks.
==21521== malloc/free: 12 allocs, 11 frees, 25,539 bytes allocated.
==21521== For counts of detected errors, rerun with: -v
==21521== searching for pointers to 1 not-freed blocks.
==21521== checked 66,236 bytes.
==21521==
==21521== 12 bytes in 1 blocks are definitely lost in loss record 1 of 1
==21521==    at 0x40215CD: malloc (vg_replace_malloc.c:149)
==21521==    by 0x80486CC: MAIN__ (in /home/daniel/pr/a.out)
==21521==    by 0x8048958: main (fmain.c:22)


-- 

dfranke at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dfranke at gcc dot gnu dot
                   |                            |org


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

[Bug fortran/32795] [4.3 regression] allocatable components are nullified prematurely

[dfranke at gcc dot gnu dot org]

------- Comment #2 from dfranke at gcc dot gnu dot org  2007-07-18 17:12 -------
In the code below, X%I is set to 0B, although the data should be still
available:

$> cat pr32795.f90
  type :: a
    integer, allocatable :: i(:)
  end type a
  type(a) :: x, y

  x = a ((/ 1,2,3 /))
  y = a (x%i(:))         ! memory leak
  print *, "<", x%i, ">"
end

$> gfortran-svn -fdump-tree-original pr31320.f90 && ./a.out
 <>

The dump shows:
    x.i.data = 0B;
before the print statement. An attempt to dealloc x afterwards follows (thus
the leak).

I will see whether I can do anything. If anyone beats me to, be welcome.
Added Paul as CC.


-- 

dfranke at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pault at gcc dot gnu dot org
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2007-07-18 17:12:34
               date|                            |
            Summary|Leaking memory (generated   |[4.3 regression] allocatable
                   |prog) with type constructor |components are nullified
                   |& allocatable components    |prematurely


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

[Bug fortran/32795] allocatable components are nullified prematurely

[dfranke at gcc dot gnu dot org]

------- Comment #3 from dfranke at gcc dot gnu dot org  2007-07-18 17:47 -------
Not a regression. 
The same happenes without the patch for PR31320, as well as with gfortran-4.2. 


-- 

dfranke at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[4.3 regression] allocatable|allocatable components are
                   |components are nullified    |nullified prematurely
                   |prematurely                 |


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

[Bug fortran/32795] allocatable components are nullified prematurely

[pault at gcc dot gnu dot org]

------- Comment #4 from pault at gcc dot gnu dot org  2007-07-28 20:52 -------
(In reply to comment #3)

Could somebody test the patch below, please?

Paul

Index: gcc/fortran/trans-stmt.c
===================================================================
*** gcc/fortran/trans-stmt.c    (revision 127010)
--- gcc/fortran/trans-stmt.c    (working copy)
*************** generate_loop_for_temp_to_lhs (gfc_expr
*** 1714,1719 ****
--- 1714,1720 ----
    stmtblock_t block, body;
    gfc_loopinfo loop1;
    tree tmp;
+   tree falselhs;
    tree wheremaskexpr;

    /* Walk the lhs.  */
*************** generate_loop_for_temp_to_lhs (gfc_expr
*** 1732,1737 ****
--- 1733,1741 ----
        tmp = gfc_build_array_ref (tmp1, count1);

        /* Use the scalar assignment as is.  */
+       falselhs = gfc_evaluate_now (lse.expr, &lse.pre);
+       falselhs = gfc_deallocate_alloc_comp (expr->ts.derived, falselhs, 0);
+       gfc_add_expr_to_block (&lse.post, falselhs);
        gfc_add_block_to_block (&block, &lse.pre);
        gfc_add_modify_expr (&block, lse.expr, tmp);
        gfc_add_block_to_block (&block, &lse.post);
*************** gfc_trans_where_assign (gfc_expr *expr1,
*** 2978,2984 ****
    /* Use the scalar assignment as is.  */
    if (sym == NULL)
      tmp = gfc_trans_scalar_assign (&lse, &rse, expr1->ts,
!                                  loop.temp_ss != NULL, false);
    else
      tmp = gfc_conv_operator_assign (&lse, &rse, sym);

--- 2982,2989 ----
    /* Use the scalar assignment as is.  */
    if (sym == NULL)
      tmp = gfc_trans_scalar_assign (&lse, &rse, expr1->ts,
!                                  loop.temp_ss != NULL,
!                                  expr2->expr_type == EXPR_VARIABLE);
    else
      tmp = gfc_conv_operator_assign (&lse, &rse, sym);


-- 


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

[Bug fortran/32795] allocatable components are nullified prematurely

[burnus at gcc dot gnu dot org]

------- Comment #5 from burnus at gcc dot gnu dot org  2007-08-01 18:39 -------
> Could somebody test the patch below, please?
Build (/= bootstrapped) and check-gfortran'ed (-m64) on x86-64-Linux.

I get an ICE (segmentation fault) for gfortran.dg/derived_comp_array_ref_1.f90:
==26501== Invalid read of size 8
==26501==    at 0x482610: structure_alloc_comps (trans-array.c:5158)
==26501==    by 0x4AB106: generate_loop_for_temp_to_lhs (trans-stmt.c:1737)

Analogously for gfortran.dg/forall_char_dependencies_1.f90 except that valgrind
does not show an error. gdb shows:

Program received signal SIGSEGV, Segmentation fault.
structure_alloc_comps (der_type=0x0, decl=0x2abe5b14b000, dest=0x0, rank=0,
purpose=1)    at trans-array.c:5158
5158      for (c = der_type->components; c; c = c->next)
#1  0x00000000004ab107 in generate_loop_for_temp_to_lhs (expr=0xf57ff0,
tmp1=0x2abe5b129f20, count3=0x0,
    count1=0x2abe5b129e70, wheremask=0x0, invert=0 '\0') at trans-stmt.c:1737


The problem is that  expr->ts.derived  == NULL in
+       falselhs = gfc_deallocate_alloc_comp (expr->ts.derived, falselhs, 0);

and that gfc_deallocate_alloc_comp simply accesses expr->ts.derived->component
without ever checking if expr->ts.derived is NULL.


-- 


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

[Bug fortran/32795] allocatable components are nullified prematurely

[burnus at gcc dot gnu dot org]

------- Comment #6 from burnus at gcc dot gnu dot org  2008-01-30 22:14 -------
Paul's patch with and added if condition (see below) nicely compiles all
examples + regtests; however, the example of comment 2 gives a wrong result
("< >" instead of "< 1 2 3 >") [this is independent of the patch]. For that
test case 12 bytes are lost according to valgrind. Actually, if one specifies
the explicit bonds, i.e.  "x%i(1:)" or "x%i(:3)" instead of "x%i(:)" or "x%i",
a temporary variable is created and "< 1 2 3 >" is correctly printed.

       /* Use the scalar assignment as is.  */
+      if (expr->ts.type == BT_DERIVED)
+       {
+         falselhs = gfc_evaluate_now (lse.expr, &lse.pre);
+         falselhs = gfc_deallocate_alloc_comp (expr->ts.derived, falselhs, 0);
+         gfc_add_expr_to_block (&lse.post, falselhs);
+       }
       gfc_add_block_to_block (&block, &lse.pre);


-- 


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

[Bug fortran/32795] allocatable components are nullified prematurely

[pault at gcc dot gnu dot org]

------- Comment #7 from pault at gcc dot gnu dot org  2008-02-07 15:19 -------
Created an attachment (id=15116)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15116&action=view)
A tentative patch for the PR

This is regtesting but all the allocatable component tests are OK.

Could somebody check the memory leakage for me, please?  The test of comment 2
is now OK in that it prints the right numbers.

Paul


-- 

pault at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |pault at gcc dot gnu dot org
                   |dot org                     |
             Status|NEW                         |ASSIGNED


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

[Bug fortran/32795] allocatable components are nullified prematurely

[dfranke at gcc dot gnu dot org]

------- Comment #8 from dfranke at gcc dot gnu dot org  2008-02-07 17:24 -------
> Could somebody check the memory leakage for me, please?

  type :: a
    integer, allocatable :: i(:)
  end type a
  type(a) :: x, y

  x = a ((/ 1,2,3 /))
! y = a (x%i(1:3))       ! ok
! y = a (x%i(1:))        ! ok
! y = a (x%i(:3))        ! ok
! y = a (x%i(:))         ! ok
! y = a (x%i)            ! ok
! y = x                  ! ok
end

Test in comment #2 works on i686-pc-linux-gnu as well.
Thanks for fixing this!


-- 


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

[Bug fortran/32795] allocatable components are nullified prematurely

[dominiq at lps dot ens dot fr]

------- Comment #9 from dominiq at lps dot ens dot fr  2008-02-07 19:52 -------
Regtested without regression on ppc/intel-darwin9, 32 and 64 bit modes.

Thanks for the patch.


-- 


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

[Bug fortran/32795] allocatable components are nullified prematurely

[pault at gcc dot gnu dot org]

------- Comment #10 from pault at gcc dot gnu dot org  2008-02-07 22:04 -------
(In reply to comment #9)
> Regtested without regression on ppc/intel-darwin9, 32 and 64 bit modes.
> 
> Thanks for the patch.
> 

Dominique and Daniel,

You mean that one-liner did it????  That represents a seriously large number of
hours to do the diagnosis:)  Ah well, I'll use #2 as a testcase and submit to
the list.

Many thanks for your help.

Paul


-- 


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

[Bug fortran/32795] allocatable components are nullified prematurely

[dfranke at gcc dot gnu dot org]

------- Comment #11 from dfranke at gcc dot gnu dot org  2008-02-07 22:10 -------
> You mean that one-liner did it????

I did not regtest, but yes, the testcases from this PR are fixed by the patch
attached in comment #7 :)


-- 


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

[Bug fortran/32795] allocatable components are nullified prematurely

[burnus at gcc dot gnu dot org]

------- Comment #12 from burnus at gcc dot gnu dot org  2008-02-07 22:17 -------
> This is regtesting but all the allocatable component tests are OK.
> Could somebody check the memory leakage for me, please?  The test of comment 2
> is now OK in that it prints the right numbers.

Thanks for the wrong-code fix; valgrind also shows no invalid accesses etc.
However, the initial bug of comment 0 is still present: As valgrind
--leak-check=full shows, the generated program still leaks memory:

==19078== 96 bytes in 1 blocks are definitely lost in loss record 1 of 2
==19078==    at 0x4C2560E: malloc (in
/usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
==19078==    by 0x401246: MAIN__ (dfdf.f90:11)
==19078==    by 0x401FDB: main (fmain.c:21)
==19078==
==19078==
==19078== 96 bytes in 1 blocks are definitely lost in loss record 2 of 2
==19078==    at 0x4C2560E: malloc (in
/usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
==19078==    by 0x400B52: MAIN__ (dfdf.f90:10)
==19078==    by 0x401FDB: main (fmain.c:21)

I think the one-liner could go into GCC 4.3.0 as it fixes a (user-visible)
wrong-code bug; still the missing _builtin_free calls should be added later.


-- 


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

[Bug fortran/32795] allocatable components are nullified prematurely

[dfranke at gcc dot gnu dot org]

------- Comment #13 from dfranke at gcc dot gnu dot org  2008-02-07 22:30 -------
> As valgrind --leak-check=full shows, the generated program still 
> leaks memory

Forgot to check this one :(

Interestingly, the error seems to be with forall only. 
The equivalent DO-loop does not leak:

  type :: a
    integer, allocatable :: i(:)
  end type a
  type :: b
    type (a), allocatable :: at(:)
  end type b
  type(a) :: x(2)
  type(b) :: y(2)
  integer i
  y(1) = b ((/x(1),x(2)/))
  y(2) = b ((/x(2),x(1)/))
 ! forall (i=1:2) y(i) = b ((/x(i)/))       ! memory leak (12 of 14)
 DO i = 1,2                                 ! frees 14 of 14
   y(i) = b ((/x(i)/))
 END DO
end


-- 


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

[Bug fortran/32795] allocatable components are nullified prematurely

[pault at gcc dot gnu dot org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 335 bytes --]



------- Comment #14 from pault at gcc dot gnu dot org  2008-02-19 12:12 -------
(In reply to comment #12)

It is essential to fix the memory leaks - that after all is the purpose behind
allocatable components.  I´ll see if I can understand what is happening.

Cheers

Paul


-- 


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

[Bug fortran/32795] allocatable components are nullified prematurely

[pault at gcc dot gnu dot org]

------- Comment #15 from pault at gcc dot gnu dot org  2008-11-24 06:35 -------
Subject: Bug 32795

Author: pault
Date: Mon Nov 24 06:34:16 2008
New Revision: 142148

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142148
Log:
2008-11-24  Paul Thomas  <pault@gcc.gnu.org>

        PR fortran/34820
        * trans-expr.c (gfc_conv_function_call): Remove all code to
        deallocate intent out derived types with allocatable
        components.
        (gfc_trans_assignment_1): An assignment from a scalar to an
        array of derived types with allocatable components, requires
        a deep copy to each array element and deallocation of the
        converted rhs expression afterwards.
        * trans-array.c : Minor whitespace.
        * trans-decl.c (init_intent_out_dt): Add code to deallocate
        allocatable components of derived types with intent out.
        (generate_local_decl): If these types are unused, set them
        referenced anyway but allow the uninitialized warning.

        PR fortran/34143
        * trans-expr.c (gfc_trans_subcomponent_assign): If a conversion
        expression has a null data pointer argument, nullify the
        allocatable component.

        PR fortran/32795
        * trans-expr.c (gfc_trans_subcomponent_assign): Only nullify
        the data pointer if the source is not a variable.

2008-11-24  Paul Thomas  <pault@gcc.gnu.org>

        PR fortran/34820
        * gfortran.dg/alloc_comp_constructor_6.f90 : New test.
        * gfortran.dg/alloc_comp_basics_1.f90 : Reduce expected refs to
        'builtin_free' from 24 to 18.

        PR fortran/34143
        * gfortran.dg/alloc_comp_constructor_5.f90 : New test.

        PR fortran/32795
        * gfortran.dg/alloc_comp_constructor_4.f90 : New test.

Added:
    trunk/gcc/testsuite/gfortran.dg/alloc_comp_auto_array_2.f90
    trunk/gcc/testsuite/gfortran.dg/alloc_comp_constructor_4.f90
    trunk/gcc/testsuite/gfortran.dg/alloc_comp_constructor_5.f90
    trunk/gcc/testsuite/gfortran.dg/alloc_comp_constructor_6.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-array.c
    trunk/gcc/fortran/trans-decl.c
    trunk/gcc/fortran/trans-expr.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gfortran.dg/alloc_comp_basics_1.f90


-- 


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

[Bug fortran/32795] allocatable components are nullified prematurely

[burnus at gcc dot gnu dot org]

------- Comment #16 from burnus at gcc dot gnu dot org  2008-11-27 13:24 -------
(Most problems have been fixed, except of the one in comment 0.)


-- 


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

[Bug fortran/32795] allocatable components are nullified prematurely

[pault at gcc dot gnu dot org]

------- Comment #17 from pault at gcc dot gnu dot org  2008-11-29 20:43 -------
Subject: Bug 32795

Author: pault
Date: Sat Nov 29 20:42:22 2008
New Revision: 142284

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142284
Log:
2008-11-24  Paul Thomas  <pault@gcc.gnu.org>

        PR fortran/34820
        * trans-expr.c (gfc_conv_function_call): Remove all code to
        deallocate intent out derived types with allocatable
        components.
        (gfc_trans_assignment_1): An assignment from a scalar to an
        array of derived types with allocatable components, requires
        a deep copy to each array element and deallocation of the
        converted rhs expression afterwards.
        * trans-array.c : Minor whitespace.
        * trans-decl.c (init_intent_out_dt): Add code to deallocate
        allocatable components of derived types with intent out.
        (generate_local_decl): If these types are unused, set them
        referenced anyway but allow the uninitialized warning.

        PR fortran/34143
        * trans-expr.c (gfc_trans_subcomponent_assign): If a conversion
        expression has a null data pointer argument, nullify the
        allocatable component.

        PR fortran/32795
        * trans-expr.c (gfc_trans_subcomponent_assign): Only nullify
        the data pointer if the source is not a variable.

2008-11-24  Paul Thomas  <pault@gcc.gnu.org>

        PR fortran/34820
        * gfortran.dg/alloc_comp_constructor_6.f90 : New test.
        * gfortran.dg/alloc_comp_basics_1.f90 : Reduce expected refs to
        'builtin_free' from 24 to 18.

        PR fortran/34143
        * gfortran.dg/alloc_comp_constructor_5.f90 : New test.

        PR fortran/32795
        * gfortran.dg/alloc_comp_constructor_4.f90 : New test.

Added:
   
branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/alloc_comp_auto_array_2.f90
   
branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/alloc_comp_constructor_4.f90
   
branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/alloc_comp_constructor_5.f90
   
branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/alloc_comp_constructor_6.f90
Modified:
    branches/gcc-4_3-branch/gcc/fortran/ChangeLog
    branches/gcc-4_3-branch/gcc/fortran/trans-array.c
    branches/gcc-4_3-branch/gcc/fortran/trans-decl.c
    branches/gcc-4_3-branch/gcc/fortran/trans-expr.c
    branches/gcc-4_3-branch/gcc/testsuite/ChangeLog
    branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/alloc_comp_basics_1.f90


-- 


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

[Bug fortran/32795] allocatable components are nullified prematurely

[pault at gcc dot gnu dot org]

------- Comment #18 from pault at gcc dot gnu dot org  2008-11-29 21:56 -------
Fixed on trunk and 4.3.

Thanks for the report!

Paul


-- 

pault at gcc dot gnu dot org changed:

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


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