[Bug fortran/63640] New: move_alloc memory leak

[Bug fortran/63640] New: move_alloc memory leak

[patnel97269-gfortran at yahoo dot fr]

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

            Bug ID: 63640
           Summary: move_alloc memory leak
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: patnel97269-gfortran at yahoo dot fr

Hi, 

The move_alloc intrisic has a memory leak, the object "from" doesn't seems to
be deallocated. Here is a small test case with integer, but leaks also for dp.

I'm using version 4.9.1 .

Thanks. 

program testmv3
  type bar
    integer, allocatable  :: ia(:), ja(:)
  end type

  integer, allocatable  :: ia(:), ja(:)
  type(bar), allocatable :: sm,sm2

  allocate(sm)
  allocate(sm2)
  allocate(sm%ia(100),sm%ja(100))
  allocate(sm2%ia(1000),sm2%ja(1000))
  allocate(ia(100),ja(1000))

  call move_alloc(ja,ia)
  call move_alloc(sm%ia,sm2%ia)

  call move_alloc(sm%ja,sm2%ja)

end program testmv3



==5438== HEAP SUMMARY:
==5438==     in use at exit: 4,992 bytes in 5 blocks
==5438==   total heap usage: 29 allocs, 24 frees, 25,211 bytes allocated
==5438== 
==5438== 96 bytes in 1 blocks are definitely lost in loss record 1 of 5
==5438==    at 0x4C29F90: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==5438==    by 0x40089A: MAIN__ (test_memleak.f90:9)
==5438==    by 0x400F66: main (test_memleak.f90:20)
==5438== 
==5438== 896 (96 direct, 800 indirect) bytes in 1 blocks are definitely lost in
loss record 4 of 5
==5438==    at 0x4C29F90: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==5438==    by 0x4009A1: MAIN__ (test_memleak.f90:10)
==5438==    by 0x400F66: main (test_memleak.f90:20)
==5438== 
==5438== 4,000 bytes in 1 blocks are definitely lost in loss record 5 of 5
==5438==    at 0x4C29F90: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==5438==    by 0x400DD7: MAIN__ (test_memleak.f90:13)
==5438==    by 0x400F66: main (test_memleak.f90:20)
==5438== 
==5438== LEAK SUMMARY:
==5438==    definitely lost: 4,192 bytes in 3 blocks
==5438==    indirectly lost: 800 bytes in 2 blocks
==5438==      possibly lost: 0 bytes in 0 blocks
==5438==    still reachable: 0 bytes in 0 blocks
==5438==         suppressed: 0 bytes in 0 blocks

[Bug fortran/63640] move_alloc memory leak

[Joost.VandeVondele at mat dot ethz.ch]

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

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

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

--- Comment #1 from Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> ---
this rather is a misunderstanding, allocatables are not necessarily freed at
the end of the main program. For example this is leak free:

> cat PR63640.f90
subroutine testmv3
  type bar
    integer, allocatable  :: ia(:), ja(:)
  end type

  integer, allocatable  :: ia(:), ja(:)
  type(bar), allocatable :: sm,sm2

  allocate(sm)
  allocate(sm2)
  allocate(sm%ia(100),sm%ja(100))
  allocate(sm2%ia(1000),sm2%ja(1000))
  allocate(ia(100),ja(1000))

  call move_alloc(ja,ia)
  call move_alloc(sm%ia,sm2%ia)

  call move_alloc(sm%ja,sm2%ja)

end subroutine testmv3

call testmv3
END

BTW, to check for leaks, you can now use the following way to compile your
code:

gfortran -fsanitize=leak PR63640.f90

without the need to run under valgrind.

[Bug fortran/63640] move_alloc memory leak

[patnel97269-gfortran at yahoo dot fr]

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

--- Comment #2 from patnel97269-gfortran at yahoo dot fr ---
Thanks for the tip and the comment.

So the standard say that move_alloc deallocate the array "from". Does that mean
that the compiler mark the array as not allocated but does not free the memory
?

[Bug fortran/63640] move_alloc memory leak

[patnel97269-gfortran at yahoo dot fr]

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

patnel97269-gfortran at yahoo dot fr changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|critical                    |normal

[Bug fortran/63640] move_alloc memory leak

[dominiq at lps dot ens.fr]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2014-12-09
     Ever confirmed|0                           |1

--- Comment #3 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Is this PR INVALID?

[Bug fortran/63640] move_alloc memory leak

[Joost.VandeVondele at mat dot ethz.ch]

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

--- Comment #4 from Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> ---
(In reply to Dominique d'Humieres from comment #3)
> Is this PR INVALID?

seems more like an enhancement request to free allocatables at the end of main.
I guess this is not mandated by the standard, but I'm actually not sure. Maybe
wontfix ?

[Bug fortran/63640] move_alloc memory leak

[mikael at gcc dot gnu.org]

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

Mikael Morin <mikael at gcc dot gnu.org> changed:

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

--- Comment #6 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to janus from comment #5)
> Right. The Fortran standard only requires the compiler to auto-deallocate
> variables which live inside a function/subroutine, but not those declared
> directly in the main program.
> 
On the other hand, allocated data should appear as "still reachable" at the end
of the program;  so the bug is we lose the pointers just before exiting?