Is it possible to DeAllocte all of allocated pointer by one order

[bohluly]

Hi Everybody

I have a DLL (Fortran) that it has a lot of pointer that they are allocated during the DLL execution, at the end of using of DLL I need to deallocate all of the allocated arraybecauseI need use DLL again from the first beforeclosing the main GUI program.

I have to find all of the allocated array anddeallocatethem ! Is there any simpler method ?

Thanks

[netphilou31]

Hi,

If possible, it would be better to allocate pointers only when needed, i.e. in the routines using them and deallocating them when leaving the procedure. In this case it would be better to locate the allocation/deallocation statements and to be sure that everything allocated gets freed at the right time.

Another possibility would be to put them in modules that allocate and deallocate them.

Phil.

[bohluly]

Dear Phil

Thanks a lot, I used Module and it is possible that I deallocate the arrays one by one, but I used pointer array in some structures and some types, and also some allocation did conditional and I need all of them before finalizing the program, so deallocation of all arrays needs a lot of controls ? I searched for a simpler method for deallocation all of them.

I needsomethinglike STOP, I checked it in DLL but it stops main program (GUI) also.

Sincerely

Asghar

[Steven_L_Intel1]

The problem is that there is no way to "reset" a DLL's global state other than unloading it and reloading. In most cases you can't do that.

If you used ALLOCATABLE variables that are local to a routine, and not with SAVE, then they get deallocated automatically when the routine exits. Otherwise I suggest you have a cleanup or initialize routine that sets everything to a known state. ALLOCATABLE is better than POINTER for this.

[bohluly]

dearSteve

Thanks a lot, yes allocatables areeasier butI have to use Pointerbecause and i have a lot pf them. I needassign mydifferentpointer touniquepointer,for some computation with thatuniquepointer.

I can use allocated() function for pointers, and I don't know there is a function for checking allocated or not allocated pointers.

I have initialize and finalize as you say but my main problem is that I have some pointers with same target.

[netphilou31]

Dear Asghar,

You can use the associated() fucntion to know if a pointer has been allocated or associated to a target so you can nullify only those that are really associated.

[fortran]if (associated(ptrX)) nullify(ptrX)[/fortran]

Anyway even if two or more pointer are pointing to the same location the thing that disassociateting them do not release the pointer memory block.

Phil.

[Steven_L_Intel1]

However, ASSOCIATED is only valid when the association status is "defined". With pointers, it may be "undefined" and you can't rely on ASSOCIATED. Calling NULLIFY is safe, of course, but doesn't release memory, as Phil says. It's unsafe to DEALLOCATE a pointer unless you know it is defined and associated with the whole of an allocation.

[netphilou31]

Steve,

I am not sure to understand when you say:

"However, ASSOCIATED is only valid when the association status is "defined". With pointers, it may be "undefined" and you can't rely on ASSOCIATED".

What do you mean by "defined" ?Does it means that when a pointer variable is never associated or allocated, the ASSOCIATED function is unable toreturn the status ?

Of course if the pointer has been allocated rather being associated you need to call the DEALLOCATE function to release the memory block instead of calling the NULLIFY function.

Phil.

[Jugoslav_Dujic]

Quoting netphilou31

What do you mean by "defined" ?Does it means that when a pointer variable is never associated or allocated, the ASSOCIATED function is unable toreturn the status ?

Exactly. Pointers have the third status, "undefined", and for those you may not query ASSOCIATED (the result is unreliable), nor try to access the memory. All you may do with such pointers is to associate them with something else. Further, you cannot query for undefined status -- you must ensure that it doesn't happen solely by program logic. That's why they are much trickier than allocatables, and should be avoided if there are alternative ways.

Here are typical situations of undefined status:

[fortran]integer, pointer:: p !unless you initialize it, pointer is initialized as "undefined"[/fortran]

Target being deallocated:

[fortran]integer, allocatable, target:: t
integer, pointer:: p
allocate(t)
p => t
deallocate(t) !p is now undefined[/fortran]

Target going out of scope:

[fortran]subroutine assoc(p)
integer, pointer:: p
integer, target:: t  !local (stack) variable
p => t
end subroutine !p is now undefined in the calling routine[/fortran]

[netphilou31]

Thanks for the comments, but what is the status of the pointer variable is such a case ?

[fortran]real(8), pointer :: p => NULL()
[/fortran]

Is it unassociated or undefined?

Phil.

[GVautier]

Hello

If I have well understood, the status of a pointer is determined by its value. If its is 0 (NULL) , it is unassociated. If not, it is presumed as associated but it is possible that the value doesn't point to a valid memory area and in this case, it is undefined.

This behaviour is identical to pointers in C.

If this is true, I think that it would be a good practice in Fortran as in C to nullify all pointers when they are declared and when they are freed or when the target itself is freed.

Allocated arrays seems to behave in he same way except that they are automatically initialized to a NULL value at declaration and set to a NULL value at deallocation. So there is no "undefined" state.

[Yaqi_Wang]

I do not understand why Fortran pointer has the undefinedstate.Does this feature have some particular usage?

[IanH]

It would take some work at runtime to always ensure that the association status of a POINTER was always defined - they can become undefined in many ways. Not all programmers would want this overhead in their programs.

Consider the following invalid program - where the DEALLOCATE statement in the main program makes the association status of ptr in the module undefined.

[fortran]MODULE PtrMod
  IMPLICIT NONE
  PRIVATE
  PUBLIC :: PointAtSomething
  PUBLIC :: UseThePointer
  INTEGER, POINTER :: ptr
  CHARACTER(*), PARAMETER :: fmt  &
      = "('associated(ptr) in ',A,' is: ',L2)"
CONTAINS
  SUBROUTINE PointAtSomething(thing)
    INTEGER, INTENT(IN), TARGET :: thing(:)
    ptr => thing(10)
    PRINT fmt, 'PointAtSomething-2', ASSOCIATED(ptr)
    PRINT *, ptr
  END SUBROUTINE PointAtSomething
  
  SUBROUTINE UseThePointer
    PRINT fmt, 'UseThePointer', ASSOCIATED(ptr)
    PRINT *, ptr
  END SUBROUTINE UseThePointer
END MODULE PtrMod

PROGRAM p
  USE PtrMod
  IMPLICIT NONE
  INTEGER, ALLOCATABLE, TARGET :: a(:)
  ALLOCATE(a(10))
  a = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
  CALL PointAtSomething(a)
  DEALLOCATE(a)
  
  ! Uh oh...
  CALL UseThePointer
END PROGRAM p
[/fortran]

[Jugoslav_Dujic]

Quoting Yaqi Wang

I do not understand why Fortran pointer has the undefinedstate.Does this feature have some particular usage?

It's not a feature which is supposed to be used; instead, it is a by-product of how pointers are designed. They point to a target, but do not "own" it. When the target disappears, there are two possible choices that the Standards committee could have done:

1) As now, do nothing with the pointer -- it becomes undefined. The alternative is to...

2) ...examine all the pointers that point to that target and nullify them. If the target is an array, that includes pointers to its subsections. To implement that, the compilers would have to do a lot of extra work, with heavy reference-counting and garbage collection.

The price of (2) is deemed too high and too complex to pay, in terms of both program efficiency and compiler writers' effort. Note that pointers to the target could exist in other program units (not visible to the compiler), so this could be easilly impossible to reliably implement. The language already has a safe mechanism of dynamic allocation (ALLOCATABLE variables), and pointers are not so crucial feature.

[jimdempseyatthecove]

Bohluly,

Assuming you have:

program YourProgram
...
do i=1,N
call SomethingInYourDLL
subroutine SomethingInYourDLL
ALLOCATE(ToPointers...)
(unable to deallocate from pointers)
end subroutine SomethingInYourDLL
(continue after call to DLL, nothing allocated by DLL will be used after call)
end do


.AND. assume all of everything allocated within DLL is to be returned

In this case consider the following:

On entry to DLL, allocate a large flat array of INTEGER(8)'s then change your ALLOCATE's to bite off a chunk of this array as needed (no deallocates) returning type required. This is a use once local heap. Then on exit from DLL you only need to deallocate this one item.

This will take some work to change the ALLOCATEs and remove the DEALLOCATEs but it may be less effort than to correct your pointer code.

Jim Dempsey

[Yaqi_Wang]

So when the target the pointer points to is released, the pointer is in the undefined status. Testing with 'associated' will tell nothing. I understand that this should be the developers' own task to use the pointer properly. Because the execution will crash anyway, it gives chances for developers to find where goes wrong. But why we make pointer undefined when it is right declared?

[jimdempseyatthecove]

Quoting Yaqi Wang

So when the target the pointer points to is released, the pointer is in the undefined status. Testing with 'associated' will tell nothing. I understand that this should be the developers' own task to use the pointer properly. Because the execution will crash anyway, it gives chances for developers to find where goes wrong. But why we make pointer undefined when it is right declared?

When a pointer points to formerly allocated memory the contents of the pointer point to a valid address in the virtual address space of the appliction. This address will not be of the former object (or array) but will be an undefined pointer into: a) heap, b) at/into subsequently allocated object, or c) heap control information.

Your program will not necessarily crash (IOW you will not receive a segment fault).

When a pointer is never initialized, it will contain random data. There is a high probability that the random data will represent an invalid virtual memory address (or unaligned pointer for an object requiring some alignment). In this situation your program will crash. When the never initialized pointer points to a valid address in the virtual memory, it may point to code as well as to other data or unallocated heap or heap control information. In this case reads might not crash the program (it will if the data is interpreted as a virtual member function or user functor), or it may crash after a write in some cases much longer after the write, and in some cases never.

Do not rely on a program crash to find your programming errors.
Conversely, do not interpret lack of program crash as indication that program is functioning correctly.

The suggestion I made earlier will work in a limited context. Think through your edits to assert that they are correct.

Jim Dempsey