DEALLOCATE in Intel FORTRAN

Question

I have found a problem when using some existing FORTRAN code. Although it had anticipated the need to deallocate arrays before re-allocating, this had never been necessary. I now need it to do this, and it doesn't function correctly.

The current pseudo-code is approximately:

MODULE mA
  TYPE A
    REAL, DIMENSION(:,:,:), ALLOCATABLE :: array
  END TYPE
  TYPE (A), POINTER :: sw(:)
END MODULE

Later, there is the code which allocates the size of 'array', which I'm now calling twice (hitherto only once):

...
IF (ALLOCATED(sw(1)%array))  DEALLOCATE(sw(1)%array, STAT=aviFail)

IF (aviFail.EQ.0) ALLOCATE(sw(1)%array(1,2,3), STAT=aviFail)
...

I've looked at the definition of ALLOCATE, DEALLOCATE and ALLOCATED, and I have found the following:

On the second time through, DEALLOCATE is called, but the STAT value is '1'
In case of failure (i.e. a positive STAT return), DEALLOCATE is meant to leave the original array untouched. It doesn't: it apparently clears it correctly (at least, according to the debugger).
In case of failure and no STAT being defined, DEALLOCATE is meant to terminate the program. It doesn't, but the following ALLOCATE statement fails with STAT value of '1'.

I had also inadvertently called ALLOCATE on the same array twice elsewhere, without DEALLOCATING first. According to the book, this should result in program termination. It not only works, but works correctly and the STAT return from the second ALLOCATE is '0'.

Does Intel FORTRAN handle these things differently, or is FORTRAN not as fussy about fulfilling its specification as C++?

Do you have a complete working example? Also, why is sw a pointer rather than just allocatable? — amaurea
I can't reproduce the problem. I manage to allocate sw twice without it complaining (since sw is a pointer, not an allocatable array), but stat always returns 0, even when try your allocate/deallocate thing twice in a row. — amaurea
Practically, failure to deallocate an allocated allocatable in a single image program means that program is hosed - memory corruption and the like. Not shown in the example code is how aviFail becomes defined when the array is not initially allocated. — IanH
I suggest trying your program with full compiler options for error checking to see if the compiler will find some problem causing memory corruption. Such as: ifort -O2 -stand f03 -check all -traceback -warn all -fstack-protector -assume protect_parens -implicitnone — M. S. B.
It sounds a lot like memory corruption, like IanH suggested. It is very hard to track down because cause and effect are far apart, and simple things like adding a print statement can completely change the symptoms. In addition to the other suggestions, I would suggest giving valgrind a try. — amaurea

whit whit · Accepted Answer · 2013-05-09T22:12:15

Without seeing more of the implementation, it is difficult to give a detailed & targeted explanation, but I think it's likely to be the implementation of the pointer that is causing your problem. The "book" answers you gave on the behavior of ALLOCATE and DEALLOCATE sound correct, but you described how they behave when working directly with an allocatable array. ALLOCATE and DEALLOCATE may function differently (compiler dependent) when operating on a pointer. At the most basic level, allocating memory through a pointer requires more steps: 1) determine the type/dimension of object to be created for the pointer, 2) create and allocate an unnamed object of that type/dimension in memory, 3) associate the pointer with the new object. Depending on the implementation, compiler, and other factors these extra steps can add complexity to the observed behavior of a program.

Is there a particular reason for using a pointer in this implementation? If not, I would recommend switching to a simpler normal allocatable array to see if the problem persists.

Regarding you being able to ALLOCATE and array twice by mistake without the expected program termination: I think this is also related to your implementation using a pointer. The pointer you are re-allocating is already associated with a location in memory. It is likely that this association changes the manner in which the compiler handles the ALLOCATE statement as it is executed the second time. If the pointer is already associated with a memory position with the dimensions the ALLOCATE statement is asking for, then there is no reason to terminate the program or throw an error; the programmer is getting exactly what he or she asked for.

In closing, the ALLOCATE/DEALLOCATE statements and pointer association/nullification are handled differently by different compilers, so it's not surprising that your observing behavior not in accordance with "the book." I would recommend taking a look at whether you really need the pointer implementation and be sure to be applying memory management best practices as you code.

DEALLOCATE in Intel FORTRAN

1 Answers