Memory leak - array of derived types and type-bound procedures

[ZlamalJakub]

I am using arrays of derived types for computation. I prepared routines for addition of two arrays of derived types

interface operator(+)
   module procedure dar_add_dar,&   ! scalar

        dar_add_dar_v   ! vector version
end interface

when I run test code on scalar derived types, it is OK. There is a memory leak (the number of allocation of memory is not the same as number of deallocations) only when vector versions of operators are used.

subroutine RunAddArrayMemoryLeak  cause memory leak.

Can someone help me to correct my code?

Attached is Visual Studio 2022 project (Windows)

Problem is when compiling using  IFX 2024.0.2 and  IFORT 2021.11.0 too.

[ZlamalJakub]

Unfortunately, I don't have experience with derived types, so I can't judge if my code is non standard or if it's a compiler problem.

I found a way to make sure my code doesn't create memory leaks and that's enough for me. My assembler knowledge is not that good to look for what is wrong deeper.

[SHARONFU]

That's very interesting indeed.

[FortranFan]

@ZlamalJakub ,

You can try two options to get around the memory-leak issues with arrays of derived types:

1. If the components of derived types in actual code are not of POINTER attribute e.g., of ALLOCATABLE attribute instead as shown here, remove the FINAL binding in the derived type i.e., go native (intrinsic) in terms of object finalization and intrinsic facilities work well in most scenarios,
2. Or, if the derived types in such code MUST have FINAL bindings, then try ELEMENTAL subroutines for the finalization e.g., the one equivalent to deinit_DAr in your original post.  If the code is doing shenanigans like reference counting using static objects (the one equivalent to module entity cnt in your original post), then the FINAL subroutines will also need to be IMPURE e.g., IMPURE ELEMENTAL.  Of course, there is the other option to "overload" the FINAL binding (generic binding) to subroutines of each rank, if that is what you prefer.

Your code has some issues in terms of standard-conformance, but memory leak problem is separate and it is related to your code design and the two suggestions above give you options to address that issue.  The standard issues are different e.g., with hard-coded KINDs e.g., integer(4) and real(8).  The literal values of 4 and 8 have no basis in the standard even if Intel Fortran, gfortran, etc. have them as extensions.  There is also the issue with style in the code shown here which is, of course, only in the eye of the beholder; but many disinterested beholders will find what is shown here quite horrible.