Memory Leak?

[L__Richard_L_]

Does the following code cause a memory leak?

type t_A;  integer, allocatable :: i(:);  end type t_A

type(t_A), allocatable :: A(:);  integer :: i

allocate (A(10))

do i = 1, 10;  call S(A(i));  end do

deallocate (A)

...

subroutine S(x);  type(t_A) :: x;  allocate (x%i(3));  end subroutine S

Or, does deallocating the outer array A automatically deallocate the embedded arrays?

[Steven_L_Intel1]

No memory leak, assuming no bugs. Deallocating the outer array is supposed to deallocate all the components. It's pretty much impossible to have a memory leak with ALLOCATABLEs given the language rules, though there have been implementation bugs in the past.

[L__Richard_L_]

Steve - I appreciate your info very much. I am in the midst of converting a big (150000 line) program to Fortran. I was afraid I would need to deallocate component-by-component bottom up.

[FortranFan]

L. Richard L. wrote:

... I was afraid I would need to deallocate component-by-component bottom up.

One big advantage of Fortran starting with the 2003 standard is the memory management rules for allocatable arrays which also offer "automatic" deallocation facility under certain circumstances, as explained in Intel Fortran help here.

So as Steve explained, assuming bug-free implementation in a compiler and when conditions explained in the above link are met, Fortran code should have no memory leaks with allocatable types even when no explicit deallocation is performed.

L. Richard L. wrote:

.. I am in the midst of converting a big (150000 line) program to Fortran...

Is it possible for you to explain this a little further?  That is, if you can share whether you're converting the program from some other language to Fortran (if yes, Wow!) or going from FORTRAN to Fortran?

[Steven_L_Intel1]

Actually, allocatable arrays were introduced in Fortran 90. Fortran 95 codified the rules for automatic deallocation and Fortran 2003 added the option of allocatable dummy arguments, function results and derived type components.

[L__Richard_L_]

When I read FortranFan's comment, my initial reaction was "UH O" because I use both pre and post 2003 compilers. Then, I felt better when I read Steve's second comment, which made me hopeful that 95 compilers will also do automatic component deallocation.  Do I have to test this?  If so, I would appreciate advice on a straightforward way to construct the test.  For example, an available function that returned the total memory currently allocated.

Regarding my conversion work, I go back and forth between Fortran and PowerBasic.  In my current project (which goes from PB to Fortran), I use a public domain varying-string module that makes heavy use of allocate. The program I am converting now has lots of allocatable arrays with varying-string components. My original question was concerned with work that deallocating these arrays might require to avoid memory leaks.

BTW - I found the public domain module very robust, very clever, easy to extend, and a good base for adding useful string functions to my toolkit.

[Steven_L_Intel1]

Fortran 2003 has deferred-length allocatable character variables which work a lot better than the varying-strings module. Many current compilers support the feature.

[FortranFan]

Steve Lionel (Intel) wrote:

Actually, allocatable arrays were introduced in Fortran 90. Fortran 95 codified the rules for automatic deallocation and Fortran 2003 added the option of allocatable dummy arguments, function results and derived type components.

I only referred to Fortran 2003 because, compared to the previous two standards, it made the overall allocatable object functionality a whole lot more practical and useful, especially with the facility for derived type components.

So if one is planning to use allocatable objects, one should actively seek out a Fortran 2003 (or higher) compiler; it will be a lot more work if one were to restrict the code to the 95 standard.

Thankfully, a whole lot of compilers now support many of Fortran 2003 features including those for the allocatable objects.