Interpretation of Dynamic Analyser Output

[dannycat]

I am trying out the Intel Inspector XE tool on one of my programs and it is telling me that I have a memory leak in the following function with the variable vec.
[bash]logical function utl_ReAllocR4Vec(vec,inc,isz) !**************************************************************** ! Re-Allocate Integer Vector Array !**************************************************************** implicit none ! Arguments real*4,allocatable :: vec(:) integer,intent(in),optional :: inc integer,intent(in),optional :: isz ! Local Variables real*4,allocatable :: temp(:) integer :: ub integer :: j integer :: ier ! Initialise ChkVec_ERR = VU_ALLOC_FAIL ! Increase if(present(inc)) then if(allocated(vec).and.inc.gt.0) then ub = ubound(vec,1) allocate(temp(ub+inc),stat=ier) if(ier.ne.0) goto 999 temp(1:ub) = vec call Move_Alloc(temp,vec) do j = ub+1, ub+inc vec(j) = 0.0 enddo endif else if(present(isz)) then if(isz.eq.0) then if(allocated(vec)) deallocate(vec) endif if(allocated(vec)) then ! Copy to new size array ub = ubound(vec,1) allocate(temp(isz),stat=ier) if(ier.ne.0) goto 999 if(isz.ge.ub) then temp(1:ub) = vec call Move_Alloc(temp,vec) do j = ub+1,isz vec(j) = 0.0 enddo else temp = vec(1:isz) call Move_Alloc(temp,vec) endif else ! Just create empty array allocate(vec(max(isz,1)),stat=ier) if(ier.ne.0) goto 999 vec = 0.0 endif endif utl_ReAllocR4Vec = .true. ChkVec_ERR = VU_ALLOC_SUCCESS return 999 continue call grp_message('Error: Cannot reallocate Real*4 array!') utl_ReAllocR4Vec = .false. return end function






I can't see how there is a leak as the allocatable array vec is passing in and out
of the function. Perhaps I need to explicitly define the argument as intent(inout).

Am I using the tool correctly?

Thanks
Steve



[/bash]

[IanH]

Is that function in a module or is it an external subprogram?

If it is an external subprogram, is an explicit interface available where the function is called? Does that explicit interface exactly match the function declaration?

(An answer of no to either of the last two questions is a bug with your program that needs to be fixed.)

[Steven_L_Intel1]

Memory leaks should not be possible with ALLOCATABLE (unless you use SAVE or there are compiler bugs). Can you provide a whole program that elicits the Inspector XE complaint?

[dannycat]

At least you do see anything awry in the coding.
This function is contained within a module, all arguments matchand I don't use the SAVE command. The full program is quite large so I will try to recreate the problem in a test. The module contains a set of reallocation functions for various types of variable (I, R4, R8, Char). I will post it on this thread when I get the example prepared.

Thanks

[Andrew_Smith]

On lines 32 and 52 you "overwrite" vec with the memory from temp without first deallocating vec. I wonder if the standard would say vec should get automatically deallocated or not.

[Steven_L_Intel1]

The standard does say, implicitly. It describes TO as "an intent(OUT) argument". This means that if vec is allocated on entry to MOVE_ALLOC, it becomes deallocated. I will check to see if that is really happening.

[Steven_L_Intel1]

I did a test and the TO argument does get deallocated automatically if it is allocated. I will see if I can construct an executable sample calling this function.

[Steven_L_Intel1]

Inspector XE, at least when I try it, complains if you don't explicitly deallocate the array before the end of the program. If you just let all allocatable storage be deallocated automatically, then it doesn't find an error. This is similar to Visual C++ debug memory leak detection, Purify and other tools I have used.

Does this match your observation?

[IDZ_A_Intel]

Steve, I've looked into this a bit more and now realise that, in my program, not all the allocatable arrays in the calling programare not deallocated before the program finishes. Ibelieve this is what you also describe. I think Inspector is correct in identifying the point at which the array is allocated but does not explicitly point to the actual array (in calling program).

In my program I was able to eliminate these memory leaks be using the debugger and checking which allocated variables are still aloocated at the end of the program.

When XE Inspector highlights memory leaksin COMCTL32.dll routines or other files outside of my program am I able to remedy these or are they alwaysinherent in the third party coding?

On the subject of allocatable arrays I havea question:

In the followingexample:

integer,allocatable :: a(:), b(:)

type struct
integer,allocatable :: i(:)
end type
type(struct) :: c, d

allocate(b(20))
allocate(d%i(20))

b =1
d%i = 2

! This
a = b ! Does not work nor does it crash the program

! However
c= d ! Works

Until recently I didn't realise that the copying of data types with allocatable components was so easy. I had always written explicit copy routines believing that they also worked on arrays. I always wodered why tracing through debug did go into my copy routine unless it was a single element to single element copy.
How long has this been available?

Request:
Can we have a neater way to read.write data types with allocatable components?

Thanks.

[IanH]

The a = b assignment requires the Fortran 2003 feature of reallocation on asssignment. Compile your example program with /standard-semantics and see what happens.

How were you calling your "explicit copy routines"? Defined assignment? If so, was the procedure implementing the defined assignment elemental?

[Steven_L_Intel1]

Ian has the answer regarding a=b. We (and some other compilers) don't enable that F2003 feature by default, though the reallocation for derived type components has been there since F90. This inconsistency was fixed in F2003.

As for your request, you are probably asking for "user-defined derived type I/O", one of the few F2003 features we don't have yet.

As for Inspector XE, it doesn't really know about variables - it tracks allocation points. But you should be able to figure out what gets allocated there. You can also enable stack traces if it's in a common routine.