I'm using gfortran -std=f2008. I have a function that returns a derived type which contains an allocatable array. The function calls allocate() before it returns. It seems like the array is being automatically deallocated some time after the function that allocated the array has returned, and my program segfaults.
When does automatic deallocation occur? Should I be coding this in a different way?
A universal answer: allocatable arrays are automatically deallocated when going out of scope. Function results are automatically deallocated after the result is "used" in the outer scope. Allocatable components are deallocated, when the parent derived type variable is going out of scope, or when it is deallocated.
Only pointers, that pointed to the function results are undefined after the deallocation and shall not be used. If you do that, it could cause the problems you describe.
Also, when an array is automatically reallocated on assignment, the pointers to it become undefined (but may not change, actually).
In other words, problems you describe shouldn't occur when the allocatables are used correctly.
Another general advice : most of the time, it is much safer to use subroutines instead of functions for returning complicated results like arrays, pointers, derived types with allocatable inside...
Additional question : do you use your function within an expression ? If not then it should be a subroutine. Fortran functions have only interest if used within calculation expressions.
Related
I have a few questions regarding dynamic variables and pointers so I can understand them better.
Are dynamic variables automatically disposed of when their scope expires? If not, then what happens?
Is the value of a pointer a memory address? If not, then what are they?
It's important to understand that there two complete separate, discreet, independent "things" that you are asking about.
A pointer to an object that was created in dynamic scope (i.e. with the new statement).
And the object itself, that the pointer is pointing to.
It's important for you two separate the two in your mind, and consider them as independent entities, in of themselves. Insofar as the actual pointer itself, its lifetime and scope are no different than any other object's. When it goes out of scope it gets destroyed.
But this has no effect on the object the pointer was pointing to. Only delete destroys the object. If there's some other pointer, that's still in scope, that points to the same object, you can use that pointer for the requisite delete.
Otherwise you end up with a memory leak.
And the value of the pointer is, for all practical purposes, a memory address. This is not specified in any form or fashion in the C++ standard, which defines pointers and objects in dynamic scope in terms of how their behavior is specified. However on all run-of-the-mill operating systems you'll see a memory address in the pointer.
It's also important to understand that since a pointer is an independent object, a pointer doesn't have to point to an object in dynamic scope. There are many pointers that don't. It's not a trivial task to keep track of all objects, all pointers, and to figure out which ones need to be deleted properly. Modern C++ has additional classes and templates that will help you do that, which you'll learn about in due time.
I have read that applying DEALLOCATE to an allocated array frees the space it was using. I deal with several allocatable arrays in my program, but never bother deallocating them. Is there a method to determine if/how not deallocating impacts the execution time?
Thanks in advance
PS: I am not prone to do this test directly (by comparing the execution time with and without deallocation) because the program depends on random variables whose values will eventually affect the performance.
Indeed, deallocation frees the memory occupied by the variables, but not always you need to do it manually.
If you know you won't need the content of the variable anymore AND you need to free up memory for other variables to be allocated (or for the system), you can use the deallocate statement.
However, deallocation occurs automatically when the variable goes out of scope (Fortran 95 or later, as pointed by #francescalus) or when you reach the end of the program.
Also, deallocation occurs automatically, when necessary, before assignment, if array's dimensions don't coincide or if the variable is polymorphic and have to assume a conformable dynamic type. (This behavior is Fortran2003 or later, and may need to be turned ON on some compilers).
Moreover, when an allocated object is argument-associated with a dummy argument that has the attribute INTENT(OUT), deallocation occur before entering the procedure.
** Warning for Pointer variables:**
If you allocated storage for a pointer variable explicitly (with the allocate statement), and after that you perform a pointer association ( => ), deallocation DOES NOT occur automatically. You are responsible for deallocating the variable before doing it or else memory leaks will happen.
As a final note, trying to deallocate a variable that is not allocated throws an error. You can check if an allocatable variable is allocated with the intrinsic function allocated.
Can deallocating variables no longer needed affect execution speed? Yes. Is it likely to in "normal" programs? No, if not preventing memory leaks.
There is no valuable heuristic of which I'm aware to help you determine usefulness of deallocating "for speed".
As previously mentioned, deallocating may be necessary for correctness or avoiding memory leaks.
However, if a program requires finalization of an allocatable variable for correctness then it will be necessary to have a deallocate statement for it: finalization does not occur when termination of execution comes about by a stop or end program statement.
Allocatable variables declared within a procedure (subroutine or function) without the save attribute (so-called unsaved local variables) are deallocated automatically when the procedure ends execution.
As a historical note, though, this wasn't true in Fortran 90. In Fortran 90 such variables were not deallocated and worse was that the allocation status of them became undefined (so that even the allocation status couldn't be queried). One really wanted a deallocate there. This deficiency was corrected in Fortran 95 but habits and code may live for a long time.
Consider the following function prototype:
swap(int &a,int &b);
'x' and 'y' are two integers local to main function.
Assume that the control is in main() function.
Now,when the compiler encounters this type of statement:swap(x,z);
What does actually happen underneath the hood(I mean,in terms of memory locations)?
My questions are:-
Is there any memory allocated for a,b in swap() function's stack?If allocated ,what would it store?
How does call by references work?
Is there any memory allocated for a,b in swap() function's stack?If allocated, what would it store?
First, consider the answer to the same question in a call to swap_ptr(int *a, int *b) Assuming that stack is used for passing parameters, some memory would be allocated to a and b in a call to swap_ptr(&x, &y). That memory would hold pointers to x and y.
The same thing happens when you pass references: some memory is allocated on the stack to pass references a and b, and initialized with references to x and y. This memory often has layout identical to a pointer, but the standard does not require this: the structure used for passing references is implementation-specific and non-transparent.
How does call by references work?
In the same way that call by value works, except the compiler knows to construct a reference, rather than making a copy of the object being passed.
Is there any memory allocated for a,b in swap() function's stack?
Excluding the possibility that the function call was expanded inline as an optimization: Yes, memory will be allocated on the call stack.
If allocated ,what would it store?
Something that can be used to access the referred object. In practice, the memory address of the referred object is used.
When you pass by value there is stack memory allocated for your object. When you pass by pointer or reference - memory on stack is only allocated for the pointer/address of the variable.
In syntax - calling by refrence works like by calling by value. But under the hood there are pointers, so dynamic dispatch using virtual functions is possible when using references.
The fundamental answer here is the difference between stack memory and heap memory.
When you pass by value you push a value onto the stack "pass by value" a space on the stack is allocated to be assigned that value (benefit here is it's very fast! but the stack is also very tightly controlled by the system).
When you pass by reference you are passing the pointer to an allocated memory object some where in the system and C++ will create a pointer to its best guess for resources out in the Heap.
Because C++ cannot anticipate the size the referenced resource will become as the program runs to completion it uses junk memory which it configures at instantiation of the application (yeah buzz words weeee)! (next time some one says "blew the stack" they are wrong, they over ran the heap, whoops! very hard to truly blow the stack, most of the time that memory is restricted)
Great article on this: http://tooslowexception.com/heap-vs-stack-value-type-vs-reference-type/
Cheers! and dont work over time its not good for you :)
In C++, this pointer get passed to method as a hidden argument which actually points to current object, but where 'this' pointer stored in memory... in stack, heap, data where?
The standard doesn't specify where the this pointer is stored.
When it's passed to a member function in a call of that function, some compilers pass it in a register, and others pass it on the stack. It can also depend on the compiler options.
About the only thing you can be sure of is that this is an rvalue of basic type, so you can't take its address.
It wasn't always that way.
In pre-standard C++ you could assign to this, e.g. in order to indicate constructor failure. This was before exceptions were introduced. The modern standard way of indicating construction failure is to throw an exception, which guarantees an orderly cleanup (if not foiled by the user's code, such as the infamous MFC placement new bug).
The this pointer is allocated on the stack of your class functions (or sometimes a register).
This is however not likely the question you are actually asking.
In C++, this is "simply" a pointer to the current object. It allows you to access object-specific data.
For example, when code in a class has the following snippet:
this->temperature = 40.0f;
it sets the temperature for whatever object is being acted upon (assuming temperature is not a class-level static, shared amongst all objects of the class).
The this pointer itself doesn't have to be allocated (in terms of dynamic memory), it depends entirely on how it's all handled under the covers, something the standard doesn't actually mandate (the standard tends to focus more on behaviour than internals).
There are any number of places it could be: on the stack, at a specific memory location, in a register, and so on. All you have to concern yourself with is its behaviour which is basically how you use it to get access to the object.
What this points to is the object itself and it's usually allocated with new for dynamic allocation, or on the stack.
The this pointer is in the object itself*. Sort of. It is the memory location of the object.
If the object is on the stack, the this pointer is on the stack.
If the object is on the heap, the this pointer is on the heap.
Bottom line, it's nothing you need to worry about.
*[UPDATE] Let me backpedal/clarify/correct my answer. The physical this pointer is not in the object.
I would conclude the this pointer is derived by the compiler and is simply the address of the object which is stored in the symbol table. Semantically, it is inside the object but that was not what the OP was asking.
Here is the memory layout of 3 variables on the stack. The middle one is an object. You can see it holds it's one variable and nothing else:
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++?
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.