[Bug fortran/49241] New: memory leak with lhs realloc of zero-sized array

[Bug fortran/49241] New: memory leak with lhs realloc of zero-sized array

[xarthisius.kk at gmail dot com]

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

           Summary: memory leak with lhs realloc of zero-sized array
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: xarthisius.kk@gmail.com


Following code causes severe memory leak with gfortran 4.6.0 (also with trunk
revision 174463)

program ala
   implicit none

   type :: array_of_foo
      real, dimension(:), allocatable :: p
   end type array_of_foo

   type(array_of_foo), dimension(:), allocatable :: tab

   integer, parameter :: lb = 0
   integer, parameter :: ub = 2
   integer, parameter :: nmax = 10
   integer :: i
   real    :: ran

   do while(.true.)
      allocate(tab(lb:ub))

      allocate(tab(lb)%p(0))
      do i = lb+1, ub
         allocate(tab(i)%p(nmax))
         tab(i)%p(:) = [(i,i=1,nmax)]
      enddo

      tab(lb)%p = [tab(lb)%p, tab(ub)%p]  !!! mem leak if first array has size
0
      ! tab(lb)%p = [tab(ub)%p, tab(lb)%p]    !!! no mem leak

      ! clean up
      do i = lb, ub
         deallocate(tab(i)%p)
      enddo
      deallocate(tab)
   enddo
end program ala

lhs realloc of size(0) = [size(0), size(n)] leaks, whereas size(0) = [size(n),
size(0)] works fine.
Following code does not exhibit this behaviour with Intel compiler (11.1.072)

[Bug fortran/49241] memory leak with lhs realloc of zero-sized array

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
                 CC|                            |burnus at gcc dot gnu.org,
                   |                            |pault at gcc dot gnu.org

--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-05-31 12:36:23 UTC ---
The memory the program needs increases continuously as "top" shows; it takes
about 5min on my computer before the OS kills it (out of memory).

If one does not use an endless loop but a finite loop, it shows no leakage with
neither valgrind nor totalview. Also the result seems to be fine - except that
the memory consumption simply grows ...

Slightly reduced test case:

program ala
   implicit none
   type :: array_of_foo
      real, dimension(:), allocatable :: p
   end type array_of_foo
   type(array_of_foo), dimension(:), allocatable :: tab
   integer :: i

   do
      allocate(tab(0:1))
      allocate(tab(0)%p(0))
      tab(1)%p = [(i,i=1,10)] ! Realloc-on assignment (fine!)
      tab(0)%p = [tab(0)%p, tab(1)%p] ! << realloc-on-assignment. Culprit?
      deallocate(tab)
   end do
end program ala

[Bug fortran/49241] memory leak with lhs realloc of zero-sized array

[xarthisius.kk at gmail dot com]

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

--- Comment #2 from Kacper Kowalik <xarthisius.kk at gmail dot com> 2011-05-31 15:12:19 UTC ---
(In reply to comment #1)
> The memory the program needs increases continuously as "top" shows; it takes
> about 5min on my computer before the OS kills it (out of memory).
> 
> If one does not use an endless loop but a finite loop, it shows no leakage with
> neither valgrind nor totalview. Also the result seems to be fine - except that
> the memory consumption simply grows ...
> 
> Slightly reduced test case:
It's not caused by reallocation, rather by array constructor? 
Test case without lhs realloc:

program ala
   implicit none
   type :: array_of_foo
      real, dimension(:), allocatable :: p
   end type array_of_foo
   type(array_of_foo), dimension(:), allocatable :: tab
   integer :: i, nn

   do
      allocate(tab(1:2))
      allocate(tab(1)%p(0))
      allocate(tab(2)%p(1))
      tab(2)%p(1) = 1.0

      nn = size( [tab(1)%p, tab(2)%p] )

      deallocate(tab(2)%p)
      deallocate(tab(1)%p)
      deallocate(tab)
   end do
end program ala

[Bug fortran/49241] memory leak with lhs realloc of zero-sized array

[xiaoyuanbo at yeah dot net]

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

xiaoyuanbo <xiaoyuanbo at yeah dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |xiaoyuanbo at yeah dot net

--- Comment #3 from xiaoyuanbo <xiaoyuanbo at yeah dot net> 2012-02-22 12:45:38 UTC ---
phsical memory main point

[Bug fortran/49241] memory leak with lhs realloc of zero-sized array

[Joost.VandeVondele at mat dot ethz.ch]

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

Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |Joost.VandeVondele at mat
                   |                            |dot ethz.ch

--- Comment #4 from Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> 2012-12-22 16:29:56 UTC ---
This doesn't reproduce for me with trunk (4.8) nor with 4.7. It does fail with
4.6. So I would say has been fixed as part of some other bug.

[Bug fortran/49241] memory leak with lhs realloc of zero-sized array

[dominiq at lps dot ens.fr]

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

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

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

--- Comment #5 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2013-02-27 12:44:30 UTC ---
Fixed by revision 188062 and branches: 4.5, 4.6 and 4.7.

*** This bug has been marked as a duplicate of bug 53521 ***