[Bug fortran/58229] New: Memory leak with overloaded operator

[Bug fortran/58229] New: Memory leak with overloaded operator

[jwmwalrus at gmail dot com]

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

            Bug ID: 58229
           Summary: Memory leak with overloaded operator
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jwmwalrus at gmail dot com

The following, reduced version of the actual code (sorry if it's still too
big), leaks memory quite fast when compiled with gfortran 4.8/4.9:

!gfortran-4.9 -o test_leak ~/test_leak.f90 
module mod1

    implicit none

    type :: pointtype
        real :: x = 0, y = 0, z = 0
    end type

    interface operator(*)
        module procedure point_times_scalar
        module procedure scalar_times_point
    end interface

contains
    elemental function point_times_scalar(point, scalar) result(res)
        !type(pointtype) :: res
        type(pointtype), allocatable :: res
        type(pointtype), intent(IN) :: point
        real, intent(IN) :: scalar
        res = pointtype(point%x * scalar, point%y * scalar, point%z * scalar)
    end function

    elemental function scalar_times_point(scalar, point) result(res)
        !type(pointtype) :: res
        type(pointtype), allocatable :: res
        real, intent(IN) :: scalar
        type(pointtype), intent(IN) :: point
        res = point * scalar
    end function
end module mod1

use mod1

implicit none

integer :: i, j
real :: x(3)
type(pointtype), allocatable :: a(:,:)

allocate (a(100,100))

do j = 1, SIZE(a,2)
    do i = 1, SIZE(a, 1)
        call RANDOM_NUMBER(x)
        a(i,j) = pointtype(x(1), x(2), x(3))
        a(i,j) = 2. * a(i,j)
        a(i,j) = 3. * a(i,j)
        a(i,j) = 4. * a(i,j)
    enddo
enddo

end




Version 4.9 seems to be leaking more memory than version 4.8.  Valgrind's
output is:

==10718== Memcheck, a memory error detector
==10718== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==10718== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==10718== Command: ./test_leak
==10718== Parent PID: 31089
==10718== 
--10718-- 
--10718-- Valgrind options:
--10718--    --suppressions=/usr/lib/valgrind/debian-libc6-dbg.supp
--10718--    -v
--10718--    --log-file=./valgrind.log
--10718--    --num-callers=100
--10718--    --leak-check=full
--10718--    --undef-value-errors=no
--10718-- Contents of /proc/version:
--10718--   Linux version 3.10-2-amd64 (debian-kernel@lists.debian.org) (gcc
version 4.7.3 (Debian 4.7.3-6) ) #1 SMP Debian 3.10.5-1 (2013-08-07)
--10718-- Arch and hwcaps: AMD64, amd64-sse3-cx16-lzcnt
--10718-- Page sizes: currently 4096, max supported 4096
--10718-- Valgrind library directory: /usr/lib/valgrind
--10718-- Reading syms from /tmp/test_leak
--10718-- Reading syms from /lib/x86_64-linux-gnu/ld-2.17.so
--10718--   Considering /lib/x86_64-linux-gnu/ld-2.17.so ..
--10718--   .. CRC mismatch (computed 1a41d356 wanted 031d690d)
--10718--   Considering /usr/lib/debug/lib/x86_64-linux-gnu/ld-2.17.so ..
--10718--   .. CRC is valid
--10718-- Reading syms from /usr/lib/valgrind/memcheck-amd64-linux
--10718--   Considering /usr/lib/valgrind/memcheck-amd64-linux ..
--10718--   .. CRC mismatch (computed 5a0963b7 wanted f2a7ec16)
--10718--   Considering /usr/lib/debug/usr/lib/valgrind/memcheck-amd64-linux ..
--10718--   .. CRC is valid
--10718--    object doesn't have a dynamic symbol table
--10718-- Scheduler: using generic scheduler lock implementation.
--10718-- Reading suppressions file: /usr/lib/valgrind/debian-libc6-dbg.supp
--10718-- Reading suppressions file: /usr/lib/valgrind/default.supp
==10718== embedded gdbserver: reading from
/tmp/vgdb-pipe-from-vgdb-to-10718-by-jwm-on-???
==10718== embedded gdbserver: writing to  
/tmp/vgdb-pipe-to-vgdb-from-10718-by-jwm-on-???
==10718== embedded gdbserver: shared mem  
/tmp/vgdb-pipe-shared-mem-vgdb-10718-by-jwm-on-???
==10718== 
==10718== TO CONTROL THIS PROCESS USING vgdb (which you probably
==10718== don't want to do, unless you know exactly what you're doing,
==10718== or are doing some strange experiment):
==10718==   /usr/lib/valgrind/../../bin/vgdb --pid=10718 ...command...
==10718== 
==10718== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==10718==   /path/to/gdb ./test_leak
==10718== and then give GDB the following command
==10718==   target remote | /usr/lib/valgrind/../../bin/vgdb --pid=10718
==10718== --pid is optional if only one valgrind process is running
==10718== 
--10718-- REDIR: 0x4017870 (strlen) redirected to 0x3806e381
(vgPlain_amd64_linux_REDIR_FOR_strlen)
--10718-- Reading syms from /usr/lib/valgrind/vgpreload_core-amd64-linux.so
--10718--   Considering /usr/lib/valgrind/vgpreload_core-amd64-linux.so ..
--10718--   .. CRC mismatch (computed 2f3ef0a4 wanted fa342ee8)
--10718--   Considering
/usr/lib/debug/usr/lib/valgrind/vgpreload_core-amd64-linux.so ..
--10718--   .. CRC is valid
--10718-- Reading syms from /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so
--10718--   Considering /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so ..
--10718--   .. CRC mismatch (computed 9eb41274 wanted 68f65041)
--10718--   Considering
/usr/lib/debug/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so ..
--10718--   .. CRC is valid
--10718-- REDIR: 0x40176e0 (index) redirected to 0x4c2c500 (index)
--10718-- REDIR: 0x4017760 (strcmp) redirected to 0x4c2d5e0 (strcmp)
--10718-- Reading syms from /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0
--10718--   Considering /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0 ..
--10718--   .. CRC mismatch (computed 10620798 wanted 7bdb0a8c)
--10718--    object doesn't have a symbol table
--10718-- Reading syms from /lib/x86_64-linux-gnu/libm-2.17.so
--10718--   Considering /lib/x86_64-linux-gnu/libm-2.17.so ..
--10718--   .. CRC mismatch (computed f2860654 wanted 54fdd28f)
--10718--   Considering /usr/lib/debug/lib/x86_64-linux-gnu/libm-2.17.so ..
--10718--   .. CRC is valid
--10718-- Reading syms from /lib/x86_64-linux-gnu/libgcc_s.so.1
--10718--   Considering /lib/x86_64-linux-gnu/libgcc_s.so.1 ..
--10718--   .. CRC mismatch (computed a7742875 wanted cd71ce72)
--10718--    object doesn't have a symbol table
--10718-- Reading syms from /usr/lib/x86_64-linux-gnu/libquadmath.so.0.0.0
--10718--   Considering /usr/lib/x86_64-linux-gnu/libquadmath.so.0.0.0 ..
--10718--   .. CRC mismatch (computed ef8c21b4 wanted 2a9b3184)
--10718--    object doesn't have a symbol table
--10718-- Reading syms from /lib/x86_64-linux-gnu/libc-2.17.so
--10718--   Considering /lib/x86_64-linux-gnu/libc-2.17.so ..
--10718--   .. CRC mismatch (computed 426a2978 wanted 1dd0f5ac)
--10718--   Considering /usr/lib/debug/lib/x86_64-linux-gnu/libc-2.17.so ..
--10718--   .. CRC is valid
--10718-- REDIR: 0x5920da0 (strcasecmp) redirected to 0x4a24720
(_vgnU_ifunc_wrapper)
--10718-- REDIR: 0x591d160 (strnlen) redirected to 0x4a24720
(_vgnU_ifunc_wrapper)
--10718-- REDIR: 0x5923070 (strncasecmp) redirected to 0x4a24720
(_vgnU_ifunc_wrapper)
--10718-- REDIR: 0x591fbb0 (memset) redirected to 0x4a24720
(_vgnU_ifunc_wrapper)
--10718-- REDIR: 0x591fb60 (memcpy@GLIBC_2.2.5) redirected to 0x4a24720
(_vgnU_ifunc_wrapper)
--10718-- REDIR: 0x591eb50 (__GI_strrchr) redirected to 0x4c2c320
(__GI_strrchr)
--10718-- REDIR: 0x5917990 (calloc) redirected to 0x4c2b490 (calloc)
--10718-- REDIR: 0x5917030 (malloc) redirected to 0x4c292f0 (malloc)
--10718-- REDIR: 0x591d080 (__GI_strlen) redirected to 0x4c2c8b0 (__GI_strlen)
--10718-- REDIR: 0x591d030 (strlen) redirected to 0x4a24720
(_vgnU_ifunc_wrapper)
--10718-- REDIR: 0x5925750 (memcpy@@GLIBC_2.14) redirected to 0x4a24720
(_vgnU_ifunc_wrapper)
--10718-- REDIR: 0x59257a0 (__GI_memcpy) redirected to 0x4c2d930
(memcpy@@GLIBC_2.14)
--10718-- REDIR: 0x591d280 (__GI_strncmp) redirected to 0x4c2cda0
(__GI_strncmp)
--10718-- REDIR: 0x5917450 (free) redirected to 0x4c2a620 (free)
==10718== 
==10718== HEAP SUMMARY:
==10718==     in use at exit: 840,000 bytes in 60,001 blocks
==10718==   total heap usage: 60,022 allocs, 21 frees, 851,799 bytes allocated
==10718== 
==10718== Searching for pointers to 60,001 not-freed blocks
==10718== Checked 99,896 bytes
==10718== 
==10718== 120,000 bytes in 1 blocks are definitely lost in loss record 1 of 7
==10718==    at 0x4C2935B: malloc (vg_replace_malloc.c:270)
==10718==    by 0x4009A1: MAIN__ (in /tmp/test_leak)
==10718==    by 0x400DB7: main (in /tmp/test_leak)
==10718== 
==10718== 120,000 bytes in 10,000 blocks are definitely lost in loss record 2
of 7
==10718==    at 0x4C2935B: malloc (vg_replace_malloc.c:270)
==10718==    by 0x400855: __mod1_MOD_scalar_times_point (in /tmp/test_leak)
==10718==    by 0x400C29: MAIN__ (in /tmp/test_leak)
==10718==    by 0x400DB7: main (in /tmp/test_leak)
==10718== 
==10718== 120,000 bytes in 10,000 blocks are definitely lost in loss record 3
of 7
==10718==    at 0x4C2935B: malloc (vg_replace_malloc.c:270)
==10718==    by 0x4008B3: __mod1_MOD_point_times_scalar (in /tmp/test_leak)
==10718==    by 0x40086C: __mod1_MOD_scalar_times_point (in /tmp/test_leak)
==10718==    by 0x400C29: MAIN__ (in /tmp/test_leak)
==10718==    by 0x400DB7: main (in /tmp/test_leak)
==10718== 
==10718== 120,000 bytes in 10,000 blocks are definitely lost in loss record 4
of 7
==10718==    at 0x4C2935B: malloc (vg_replace_malloc.c:270)
==10718==    by 0x400855: __mod1_MOD_scalar_times_point (in /tmp/test_leak)
==10718==    by 0x400CA8: MAIN__ (in /tmp/test_leak)
==10718==    by 0x400DB7: main (in /tmp/test_leak)
==10718== 
==10718== 120,000 bytes in 10,000 blocks are definitely lost in loss record 5
of 7
==10718==    at 0x4C2935B: malloc (vg_replace_malloc.c:270)
==10718==    by 0x4008B3: __mod1_MOD_point_times_scalar (in /tmp/test_leak)
==10718==    by 0x40086C: __mod1_MOD_scalar_times_point (in /tmp/test_leak)
==10718==    by 0x400CA8: MAIN__ (in /tmp/test_leak)
==10718==    by 0x400DB7: main (in /tmp/test_leak)
==10718== 
==10718== 120,000 bytes in 10,000 blocks are definitely lost in loss record 6
of 7
==10718==    at 0x4C2935B: malloc (vg_replace_malloc.c:270)
==10718==    by 0x400855: __mod1_MOD_scalar_times_point (in /tmp/test_leak)
==10718==    by 0x400D27: MAIN__ (in /tmp/test_leak)
==10718==    by 0x400DB7: main (in /tmp/test_leak)
==10718== 
==10718== 120,000 bytes in 10,000 blocks are definitely lost in loss record 7
of 7
==10718==    at 0x4C2935B: malloc (vg_replace_malloc.c:270)
==10718==    by 0x4008B3: __mod1_MOD_point_times_scalar (in /tmp/test_leak)
==10718==    by 0x40086C: __mod1_MOD_scalar_times_point (in /tmp/test_leak)
==10718==    by 0x400D27: MAIN__ (in /tmp/test_leak)
==10718==    by 0x400DB7: main (in /tmp/test_leak)
==10718== 
==10718== LEAK SUMMARY:
==10718==    definitely lost: 840,000 bytes in 60,001 blocks
==10718==    indirectly lost: 0 bytes in 0 blocks
==10718==      possibly lost: 0 bytes in 0 blocks
==10718==    still reachable: 0 bytes in 0 blocks
==10718==         suppressed: 0 bytes in 0 blocks
==10718== 
==10718== ERROR SUMMARY: 7 errors from 7 contexts (suppressed: 0 from 0)
==10718== ERROR SUMMARY: 7 errors from 7 contexts (suppressed: 0 from 0)




And the system info is:

...:/tmp$ ll `which gfortran-4.9` && /usr/lib/gcc-snapshot/bin/gfortran -v &&
apt-cache policy gfortran-4.8 gcc-snapshot && lsb_release -rd
lrwxrwxrwx 1 root staff 35 Aug 17 21:16 /usr/local/bin/gfortran-4.9 ->
../../lib/gcc-snapshot/bin/gfortran*
Using built-in specs.
COLLECT_GCC=/usr/lib/gcc-snapshot/bin/gfortran
COLLECT_LTO_WRAPPER=/usr/lib/gcc-snapshot/libexec/gcc/x86_64-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 20130821-1'
--with-bugurl=file:///usr/share/doc/gcc-snapshot/README.Bugs
--enable-languages=c,ada,c++,java,go,fortran,objc,obj-c++
--prefix=/usr/lib/gcc-snapshot --enable-shared --enable-linker-build-id
--disable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-snap-amd64/jre
--enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-snap-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-snap-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --with-tune=generic --disable-werror
--enable-checking=yes --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.0 20130821 (experimental) [trunk revision 201901] (Debian
20130821-1) 
gfortran-4.8:
  Installed: 4.8.1-9
  Candidate: 4.8.1-9
  Version table:
 *** 4.8.1-9 0
        200 http://ftp.us.debian.org/debian/ unstable/main amd64 Packages
        100 /var/lib/dpkg/status
     4.8.1-2 0
        500 http://ftp.us.debian.org/debian/ testing/main amd64 Packages
gcc-snapshot:
  Installed: 20130821-1
  Candidate: 20130821-1
  Version table:
 *** 20130821-1 0
        200 http://ftp.us.debian.org/debian/ unstable/main amd64 Packages
        100 /var/lib/dpkg/status
Description:    Debian GNU/Linux testing (jessie)
Release:    testing

[Bug fortran/58229] [F03] Memory leak with allocatable function result

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-08-23
                 CC|                            |janus at gcc dot gnu.org
            Summary|Memory leak with overloaded |[F03] Memory leak with
                   |operator                    |allocatable function result
     Ever confirmed|0                           |1

--- Comment #1 from janus at gcc dot gnu.org ---
Confirmed. Reduced test case:


  implicit none

  type :: pointtype
    real :: x = 0, y = 0, z = 0
  end type

  integer :: i, j
  real :: x(3)
  type(pointtype), allocatable :: a(:,:)

  allocate (a(10,10))

  do j = 1, SIZE(a,2)
    do i = 1, SIZE(a, 1)
      call RANDOM_NUMBER(x)
      a(i,j) = pointtype(x(1), x(2), x(3))
      a(i,j) = scalar_times_point (2. , a(i,j))
    enddo
  enddo

contains

  function scalar_times_point(scalar, point) result(res)
    type(pointtype), allocatable :: res
    real, intent(IN) :: scalar
    type(pointtype), intent(IN) :: point
    res = pointtype(point%x * scalar, point%y * scalar, point%z * scalar)
  end function

end


It is not really connected to operators, but rather to allocatable function
results in general. The variant above shows two leaks with 4.9 trunk:


==31477== 1,200 bytes in 1 blocks are definitely lost in loss record 1 of 2
==31477==    at 0x4C2C27B: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==31477==    by 0x400986: MAIN__ (c0.f90:11)
==31477==    by 0x400C9E: main (c0.f90:13)
==31477== 
==31477== 1,200 bytes in 100 blocks are definitely lost in loss record 2 of 2
==31477==    at 0x4C2C27B: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==31477==    by 0x400898: scalar_times_point.1878 (c0.f90:27)
==31477==    by 0x400C0E: MAIN__ (c0.f90:17)
==31477==    by 0x400C9E: main (c0.f90:13)


The first one is the ALLOCATE in the main program, which (according to F08) is
*not* required to be auto-deallocated (4.8 does it, but 4.9 doesn't, so this
explains the difference between the two). This is not a bug.

The second one is the allocate-on-assignment inside the function, which nevers
gets freed. This *is* a bug. What should be done is: Create a temporary for the
function result and free it after the call. This is also one of the cases where
finalization still needs to be handled (cf. PR 37336).

[Bug fortran/58229] [F03] Memory leak with allocatable function result

[janus at gcc dot gnu.org]

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

--- Comment #2 from janus at gcc dot gnu.org ---
(In reply to janus from comment #1)
> The second one is the allocate-on-assignment inside the function, which
> nevers gets freed. This *is* a bug. What should be done is: Create a
> temporary for the function result and free it after the call.

This probably needs to happen inside gfc_conv_procedure_call (trans-expr.c).

[Bug fortran/58229] [F03] Memory leak with allocatable scalar function result

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[F03] Memory leak with      |[F03] Memory leak with
                   |allocatable function result |allocatable scalar function
                   |                            |result

--- Comment #3 from janus at gcc dot gnu.org ---
As the following test case demonstrates, the leak actually only happens for
allocatable *scalar* results. Array results already get a temporary, which is
passed as argument and deallocated after the call.


  implicit none
  integer :: i, arr(1:3)
  i = alloc_result_scalar ()
  arr = alloc_result_array ()

contains

  function alloc_result_scalar () result(res)
    integer, allocatable :: res
    allocate(res)
    res = 42
  end function

  function alloc_result_array () result(res)
    integer, dimension(:), allocatable :: res
    allocate(res(1:3))
    res = (/ 41, 42, 43 /)
  end function

end

[Bug fortran/58229] [F03] Memory leak with allocatable scalar function result

[burnus at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |burnus at gcc dot gnu.org
         Resolution|---                         |DUPLICATE

--- Comment #4 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Duplicate of PR55603 (or PR46487).

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