Inspector XE question about memory leak

[Brian_Murphy]

I am new at using the Intel Inspector. It is telling me there is a memory leak at the following line ALLOCATE ( CEIG%VAL(N5), CEIG%VEC(N5, N5), STAT=IERR) What would make it think there is a memory leak? I am confident these variables have not already been allocated. The derived data type is defined in a module file as follows: TYPE C_EIGEN ! VAL = Complex Eigenvalue, ! VEC = Complex Eigenvector. COMPLEX(8), POINTER :: VAL(:), VEC(:,:) END TYPE C_EIGEN The CEIG variable is being passed around in a COMMON block dedicated to this one variable. The above ALLOCATE statement appears in several subroutines, only one of which gets run. There is a single DEALLOCATE statement at the end of the main program. This is a rather ordinary console application. Is there something wrong with this syntax? Does there need to be an ALLOCATABLE statement somewhere (right now, there's not)? Thanks, Brian in Austin, TX

[Brian_Murphy]

The Inspector is also saying there is a memory leak in this call to date_and_time INTEGER(4) START_TIME(8) CALL DATE_AND_TIME(VALUES=START_TIME) What's wrong with this??? Should INTEGER(4) be just INTEGER?

[Steven_L_Intel1]

I'd need to see a complete program - sometimes Inspector doesn't understand Fortran as well as it could, but it is getting better.

The memory leak for DATE_AND_TIME would probably be inside the library routine - rather interesting. I will try some experiments with this myself. There's nothing wrong with your code.

[jimdempseyatthecove]

The IVF documentation states INTEGER, not INTEGER(4).

Compile with /warn:interfaces

Regardless of this, the CALL should not have caused a memory leak (unless the runtime library has an error, or looks like it has an error).

Regarding the ALLOCATE. How large are your allocations? (what is N5)

Also, in your type declaration for C_EIGEN, use

COMPLEX(8), POINTER :: VAL(:) => NULL()
COMPLEX(8), POINTER :: VEC(:,:) => NULL()

Then prior to ALLOCATE insert a sanity check:
IF(ASSOCIATED(CEIG%VAL) .OR. ASSOCIATED(CEIG%VEC)) THEN
WRITE(*,*) "You have a bug" ! place break on this line
ENDIF

Jim Dempsey

[Steven_L_Intel1]

Ok, looked into this some more. The "leak" is in the Microsoft Visual C++ DLL library and is harmless. There is only one allocation of the memory per thread, and it can't be deallocated. You need not be concerned about it, though you're quite right to ask.

[Brian_Murphy]

I can certainly send you the code, but I'm not sure how to do it. The project is one of about 10 in a Solution. I've zipped up just this project in a 14 mb zip file. Do you want it?

[Brian_Murphy]

I will put in the null() initializers and see what that does. N5 was less than 100. I think it was 40. Many of the errors being flagged by this Inspector thing seem to be false.

[Steven_L_Intel1]

Do a Build > Clean on the solution and then try zipping it again. In my experience, Inspector often finds real things, but sometimes there are issues you can't do anything about and other times they're false positives.  We continue to work on improving it.

[Brian_Murphy]

Ok.  I did the clean and rebuilt the project.  I've cleaned up about 5 or so minor things that the Inspector found, but these were all pretty harmless.  The Inspector is still telling me I've got about 40 memory leak and invalid memory access errors which don't make any sense at all.

How do you want me to send you the zip file? I don't want to post it to the forum.

[Steven_L_Intel1]

You can use "Send Author A Message" and attach it there, you can email it to me at Steve.Lionel at intel dot com, or you can use Intel Premier Support and ask that the issue be assigned to me.