[Bug fortran/38319] Memory leaks in allocatable component expressions

[Bug fortran/38319] Memory leaks in allocatable component expressions

[pault at gcc dot gnu dot org]

-- 

pault at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2008-11-29 21:54:13
               date|                            |


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

[Bug fortran/38319] New: Memory leaks in allocatable component expressions

[pault at gcc dot gnu dot org]

The following testsuite programs with allocatable components exhibit memory
leaks at runtime:
alloc_comp_assign_2.f90      FOR_ALL problem(lines 27, 28 and 47)
alloc_comp_assign_4.f90      nested constructors(line 56)
alloc_comp_basics_2.f90      repeated ALLOCATE (lines 29, 30 and 35)
alloc_comp_basics_5.f90      repeated ALLOCATE (lines 29, 30 and 35)
alloc_comp_constructor_2.f90 nested constructors(line 23)
alloc_comp_initializer_1.f90 nested constructors(line 43)

Clearly, the investigation should go in the order:
nested constructors => repeated ALLOCATE => FORALL

Paul


-- 
           Summary: Memory leaks in allocatable component expressions
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Keywords: wrong-code
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: pault at gcc dot gnu dot org
        ReportedBy: pault at gcc dot gnu dot org


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

[Bug fortran/38319] Memory leaks in allocatable component expressions

[burnus at gcc dot gnu dot org]

------- Comment #1 from burnus at gcc dot gnu dot org  2009-07-30 19:07 -------
See also http://gcc.gnu.org/ml/fortran/2009-07/msg00260.html and PR 40899.


-- 


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

[Bug fortran/38319] Memory leaks in allocatable component expressions

[pault at gcc dot gnu dot org]

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



------- Comment #2 from pault at gcc dot gnu dot org  2010-02-24 20:31 -------
I have been having trouble in recent times detecting these memory leaks. 
Neither FC9 nor RHEL5.2 x86_64 seem to show them with valgrind.  Since I know
that others still see them, I wonder are there any ideas what I have to do to
detect them?  It´s a tad difficult to fix the memory leaks if I cannot detect
them :-)

Paul


-- 


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

[Bug fortran/38319] Memory leaks in allocatable component expressions

[burnus at gcc dot gnu dot org]

------- Comment #3 from burnus at gcc dot gnu dot org  2010-02-25 07:38 -------
Paul, can you try with  valgrind --leak-check=full ? Without the =full option,
I also do not get any line info output but just in the summary "definitely
lost: 288 bytes in 4 blocks".


-- 


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

[Bug fortran/38319] Memory leaks in allocatable component expressions

[paul dot richard dot thomas at gmail dot com]

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



------- Comment #4 from paul dot richard dot thomas at gmail dot com  2010-02-25 12:50 -------
Subject: Re:  Memory leaks in allocatable component 
        expressions

> ------- Comment #3 from burnus at gcc dot gnu dot org  2010-02-25 07:38 -------
> Paul, can you try with  valgrind --leak-check=full ? Without the =full option,
> I also do not get any line info output but just in the summary "definitely
> lost: 288 bytes in 4 blocks".

Tobias,

I cannot remember how valgrind puts it but I get the no memory leaks
possible message, even with =full.

Cheers

Possible


-- 


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

[Bug fortran/38319] Memory leaks in allocatable component expressions

[burnus at gcc dot gnu dot org]

------- Comment #5 from burnus at gcc dot gnu dot org  2010-02-25 13:54 -------
  type :: thytype
    integer(4), allocatable :: h(:)
  end type thytype
  type :: mytype
    type(thytype), allocatable :: q(:)
  end type mytype
  type (mytype) :: x
  x = mytype ([thytype([555])])
end

Reduced test case. If I read the dump correctly, one effectively does:

 tmp = thytype([555])
 x = mytype(tmp)

however, for "mytype(tmp)" the data is copied instead of simply assigning the
pointer "tmp.data" and "tmp.data" is never freed.

a) One creates "thytype" with the value 555:
  (*(struct thytype[1] * restrict) atmp.1.data)[0] = thytype.4;
- and recopying again:
  (*(struct thytype[1] * restrict) atmp.7.data)[S.9] = (*(struct thytype[1] *
restrict) atmp.1.data)[S.9];

b) One now assigns that data to "mytype" - but not directly but via
malloc+memcopy:
   D.1592 = (void * restrict) __builtin_malloc (MAX_EXPR <D.1591, 1>);
   (*(struct thytype[0:] * restrict) mytype.0.q.data)[S.10].h.data = D.1592;
   __builtin_memcpy ((integer(kind=4)[0:] * restrict) (*(struct thytype[0:] *
restrict) mytype.0.q.data)[S.10].h.data, (integer(kind=4)[0:] * restrict)
(*(struct thytype[1] * restrict) atmp.7.data)[S.10].h.data, D.1590 * 4);

The problem is now that "atmp.7.data.h.data" is never freed.

It would be fantastic if instead of freeing atmp.7.data.h.data one could simply
assign atmp.7.data.h.data to mytype.0.q.data[S.10].h.data without
malloc/memcpy. I am sure it is nontrivial, but I would really like to see the
number of temporaries be cut down. The dumps are pretty hard to read and we
probably give also the middle end a hard time in figuring out that we do not
need ~8 mallocs but one three - especially since the middle end does not really
optimize malloc/free (it could, but it doesn't - yet).


-- 


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