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