Bug 49241 - memory leak with lhs realloc of zero-sized array
Summary: memory leak with lhs realloc of zero-sized array
Status: RESOLVED DUPLICATE of bug 53521
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.6.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: wrong-code
Depends on:
Blocks:
 
Reported: 2011-05-31 11:11 UTC by Kacper Kowalik
Modified: 2013-02-27 12:44 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Kacper Kowalik 2011-05-31 11:11:18 UTC 
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)
Comment 1 Tobias Burnus 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
Comment 2 Kacper Kowalik 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
Comment 3 xiaoyuanbo 2012-02-22 12:45:38 UTC 
phsical memory main point
Comment 4 Joost VandeVondele 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.
Comment 5 Dominique d'Humieres 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 ***