move_alloc for types holding allocatable members

Alberto Luaces aluaces@udc.es
Fri Oct 9 08:23:00 GMT 2015


Steve Kargl writes:

> So, yes, I believe you have the arguments backwards.

Of course you are right.  It was a bug on my code, sorry about that and
thank you for your throughout analysis.

I have corrected the example code to mimic what our production code
does.  I also forgot copying old data to the new array before the call
to move_alloc.

After growing the array from 7 elements (OLDSIZE) to 20 (NEWSIZE), and
then deallocating, valgrind warns me about 7 leaked blocks.  They are
likely the allocations for the first 7 sub-elements.

I have checked this example on a different compiler and shows no leaks.
That is what led me to think that it might be a bug.

--8<---------------cut here---------------start------------->8---
module alloctest

  type myallocatable
     integer, allocatable:: i(:)
  end type myallocatable

contains
  subroutine f(num, array)
    implicit none
    integer, intent(in) :: num
    integer :: i
    type(myallocatable):: array(:)

    do i = 1, num
       allocate(array(i)%i(5))
    end do

  end subroutine f
end module alloctest

program name
  use alloctest
  implicit none
  type(myallocatable), allocatable:: myarray(:), mytemp(:)
  integer, parameter:: OLDSIZE = 7, NEWSIZE = 20

  allocate(myarray(OLDSIZE))
  call f(size(myarray), myarray)

  allocate(mytemp(NEWSIZE))
  mytemp(1:OLDSIZE) = myarray

  call move_alloc(mytemp, myarray)

  deallocate(myarray)
end program name
--8<---------------cut here---------------end--------------->8---

==9262== Memcheck, a memory error detector
==9262== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==9262== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==9262== Command: ./ra
==9262== 
==9262== 
==9262== HEAP SUMMARY:
==9262==     in use at exit: 140 bytes in 7 blocks
==9262==   total heap usage: 40 allocs, 33 frees, 13,817 bytes allocated
==9262== 
==9262== 140 bytes in 7 blocks are definitely lost in loss record 1 of 1
==9262==    at 0x4C28C4F: malloc (vg_replace_malloc.c:299)
==9262==    by 0x400985: __alloctest_MOD_f (in /testsFortran/ra)
==9262==    by 0x400DBB: MAIN__ (in /testsFortran/ra)
==9262==    by 0x401433: main (in /testsFortran/ra)
==9262== 
==9262== LEAK SUMMARY:
==9262==    definitely lost: 140 bytes in 7 blocks
==9262==    indirectly lost: 0 bytes in 0 blocks
==9262==      possibly lost: 0 bytes in 0 blocks
==9262==    still reachable: 0 bytes in 0 blocks
==9262==         suppressed: 0 bytes in 0 blocks
==9262== 
==9262== For counts of detected and suppressed errors, rerun with: -v
==9262== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)


-- 
Alberto



More information about the Fortran mailing list