Confusing behavior of ASSOCIATED function

[chstoyer]

I am using Visual Fortran 2011.2.154.

If I try to deallocate arrays that have not been allocated, I get a severe error, even though I have included the STAT= parameter in the deallocation statement.

fortl: severe (157) Program Exception - access violation

Unhandled exception at 0x0174adcc in IXRefraX.exe: 0xC0000005: Access violation reading location 0xcdcdcdc9.

And then I end up in a tab called dbgheap.c:

extern "C" static int __cdecl CheckBytes(

unsigned char * pb,

unsigned char bCheck,

size_t nSize

)

{

while (nSize--)

{

if (*pb++ != bCheck)

{

return FALSE;

}

}

return TRUE;

}

stopping at the code line shown in bold.

The variables are declared as

REAL, POINTER, DIMENSION (:) :: PosL1,PosL2,TimeL1,TimeL2,VelFlatL,PosR1,PosR2,TimeR1,TimeR2,VelFlatR

I try to deallocate as

DEALLOCATE (PF%SH(I)%PosL1,PF%SH(I)%PosL2,PF%SH(I)%TimeL1,PF%SH(I)%TimeL2,PF%SH(I)%VelFlatL,&

PF%SH(I)%PosR1,PF%SH(I)%PosR2,PF%SH(I)%TimeR1,PF%SH(I)%TimeR2,PF%SH(I)%VelFlatR,PF%SH(I)%IFitL,&

PF%SH(I)%IFitR,STAT=IALERR)

I can look at PF%SH(I) in the debugger and all the variables are allocated, except for those in the above DEALLOCATE statement, which are shown as undefined pointer array (as they should be)

So then I test to see if the first one is allocated:

IF(ASSOCIATED(PF%SH(I)%PosL1))...

It tries to deallocate them even though looking at ASSOCIATED(PF%SH(I)%PosL1) in the debugger shows it is .FALSE. or #00000000 hex. So I introduce an intermediate variable:

LALLOCATED=ASSOCIATED(PF%SH(I)%PosL1)

IF(LALLOCATED)THEN

DEALLOCATE (PF%SH(I)%PosL1,...

Again, the ASSOCIATED() function shows up in the debugger as .FALSE. or #00000000 but LALLOCATED shows up as .TRUE. #FFFFFFFFn hex.

I tried ALLOCATED instead of ASSOCIATED, but of course it gave me a compiler error because the variables are pointers, not allocatable arrays.

It seems to me that as long as I include the STAT= in the DEALLOCATE statement, it should not crash but just return the error code. Also it seems to me that if the intrinsic function ALLOCATE(arg) is .FALSE. then the variable which is set equal to the function should also be .FALSE.

Suggestions welcome,

Charles

[mecej4]

Have you checked whether you have any uninitialized pointers that you are handing off to DEALLOCATE? If so, you may want to consider providing default initialization to NULL() for the pointer components in your derived type variables.

[Steven_L_Intel1]

I suspect you are corrupting memory somewhere. But let me suggest you replace POINTER with ALLOCATABLE as this may make things easier for you. In particular, if you DEALLOCATE a variable of derived type with ALLOCATABLE components (be sure to replace POINTER with ALLOCATABLE in the type definition too), then all the components will get deallocated.

In today's Fortran, POINTER should be restricted to those cases where you want to use pointer assignment and not for general dynamic allocation.

[chstoyer]

Thank you. I had forgotten that bad things happen when pointers aren't initialized to null.

That fixed it.

Charles

[chstoyer]

I had forgotten to nullify the new pointers I added to initialize them. When I did that, it was fixed. I am not sure why I moved from ALLOCATABLE to POINTER. It was several years ago and there was a reason which I don't remember.

Anyway, it would be a bit of work to go back and change them all.

Thanks for your advice, though.

Charles

[Arjen_Markus]

In plain Fortran 90/95 (that is: no support for the techical report describing allocatable components and dummy arguments and so on) pointer variables are required to have flexibly-sized components. My guess
is that was the reason. I think most if not all of current compilers support at least that feature of Fortran 2003. So it is quite portable to use the allocatable attribute instead of pointer, just as Steve suggested.

Regards,

Arjen