PRIVATE statement in UDDT causes memory leak with ALLOCATABLE components?

[Paul van Delst]

Hello,

I have the following derived type definition:

TYPE :: PtrArr_type
INTEGER :: n = 0
REAL(fp), ALLOCATABLE :: Arr(:)
END TYPE PtrArr_type

that has an associated Destroy function:

FUNCTION Destroy_PtrArr(p) RESULT(err_status)
! Arguments
TYPE(PtrArr_type), INTENT(OUT) :: p
! Function result
INTEGER :: err_status
! Set up
err_status = SUCCESS
END FUNCTION Destroy_PtrArr

Note for this test I rely upon the INTENT(OUT)-ness of the argument to do the actual
deallocation. I have tested this and it works fine (no memory leaks). All of the above is
in its own module.

In a separate module, I now use the above derived type in another definition:

TYPE :: oSRF_type
PRIVATE
REAL(fp), ALLOCATABLE :: f1(:)
TYPE(PtrArr_type), ALLOCATABLE :: Frequency(:)
TYPE(PtrArr_type), ALLOCATABLE :: Response(:)
END TYPE oSRF_type

with its similar destruction routine

FUNCTION Destroy_oSRF(oSRF) RESULT(err_status)
! Arguments
TYPE(oSRF_type), INTENT(OUT) :: oSRF
! Function result
INTEGER :: err_status
! Set up
err_status = SUCCESS
END FUNCTION Destroy_oSRF

When I compile the code modules in question along with a test program and run it through
valgrind I get the following memory leak summary output:

==17651== LEAK SUMMARY:
==17651== definitely lost: 1,408 bytes in 16 blocks.
==17651== possibly lost: 0 bytes in 0 blocks.
==17651== still reachable: 64,848 bytes in 1 blocks.
==17651== suppressed: 0 bytes in 0 blocks.
==17651== Use --leak-check=full to see details of leaked memory.

If I *only* comment out the PRIVATE statement within the oSRF_type definition and
recompile, I get the following from valgrind:

==17684== LEAK SUMMARY:
==17684== definitely lost: 0 bytes in 0 blocks.
==17684== possibly lost: 0 bytes in 0 blocks.
==17684== still reachable: 68,700 bytes in 1 blocks.
==17684== suppressed: 0 bytes in 0 blocks.
==17684== Reachable blocks (those to which a pointer was found) are not shown.
==17684== To see them, rerun with: --show-reachable=yes

I'm at a bit of a loss to figure out why commenting out the private statement causes the
memory leaks to disappear. Or why they occur in the first place. Is it because my simple
understanding of the garbage handling of f95 tr15581 allocatables doesn't extend down into
subcomponents?

I'm still trying to get a small test case together that I can post here (my initial very
simple attempt had no leaks no matter what I did). Probably by the time I have a simple
test case it will have shown me what is wrong but, until then, anyone have any ideas? Am I
missing something glaringly obvious? The standard didn't seem to have any restrictions
regarding the ALLOCATABLE attribute for components and an "internal" PRIVATE access
specifier for derived types.

cheers,

paulv

p.s. My compiler:

$ oSRF/Test_oSRF : gfortran --version
GNU Fortran (GCC) 4.4.0 20090219 (experimental) [trunk revision 144294]