# Program does not return from\`deallocate\` statement **URL:** \ **Category:** Help\ **Created:** [January 4, 2023, 3:46pm UTC](https://fortran-lang.discourse.group/t/program-does-not-return-from-deallocate-statement/4975 "2023-01-04T15:46:40Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![mEm](https://avatars.discourse-cdn.com/v4/letter/m/90ced4/32.png) [@mEm](https://fortran-lang.discourse.group/u/mEm)\ **Post date:** [January 4, 2023, 3:46pm UTC](https://fortran-lang.discourse.group/t/program-does-not-return-from-deallocate-statement/4975/1 "2023-01-04T15:46:40Z")
Hi to everyone, wish you all a good 2023! I’m having a problem in the execution of a program, which at some point hangs at the level of a `deallocate` statement. It’s surely related to some bad memory mangement, though I’m using `/heap-arrays /check:all /debug:all /Od` and no RT error is thrown. I tried using the VS’s built-in heap allocation tracker, but without useful outcome. If you’d have any suggestion on how to face this issue, I’d more than happy to hear them. Cheers, Michele **EDIT** : I had forgot to mention that, the issue shows only after a given dimension (fom which some big bunch of allocations depend) is greater than say `x=17`, where the actual threshold value `x` does not seem to be meaningful (just _random_). **EDIT 2** : Also, I am afraid that the problem might be “bigger than it seems”. What I mean by that, is because this issue happens only when the logic of the program passes through some procedures which use (externally, statically linked) LAPACK procedures. I already had some _very strange_ behavious, at the very lines of calling those routines (some memory overlapping, which was ending up in unintentional memory overriding). This should have been fixed already. Or, this is what I think… So, I am afraid that this issue might somewhat be related to what I was having before. **NOTE** : this _failing_ routine is called within a loop. The failing does not happen at the very first loop iteration, but after some. In the middle, no other `allocation/deallocation` happen if not for the variables in question. ---
**Author:** ![Beliavsky](https://avatars.discourse-cdn.com/v4/letter/b/ba8739/32.png) [@Beliavsky](https://fortran-lang.discourse.group/u/Beliavsky)\ **Post date:** [January 4, 2023, 3:54pm UTC](https://fortran-lang.discourse.group/t/program-does-not-return-from-deallocate-statement/4975/2 "2023-01-04T15:54:09Z")
Welcome to the forum. DEALLOCATE cannot be used on an array that is not ALLOCATEd. I don’t know if this is the problem, but it is the first thing I would look for, based on experience. What happens if you write `if (allocated(x)) deallocate(x)` instead of `deallocate(x)` ---
**Author:** ![mEm](https://avatars.discourse-cdn.com/v4/letter/m/90ced4/32.png) [@mEm](https://fortran-lang.discourse.group/u/mEm)\ **Post date:** [January 4, 2023, 3:57pm UTC](https://fortran-lang.discourse.group/t/program-does-not-return-from-deallocate-statement/4975/3 "2023-01-04T15:57:25Z")
@Beliavsky, thanks for your answer. I’m surely not an expert as you are, but I know a bit of Fortran 😛 And what you suggest is exactly what I do. I could actually also remove those lines because allocation happens within a procedure, but I added them to see which one was failing. Of course, before program did not return from that procedure (same issue). PS: in that case, I guess the RT would have complained about that, trying to reference an `allocatable` not being `allocate`d. ---
**Author:** ![PierU](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/pieru/32/1848_2.png) [@PierU](https://fortran-lang.discourse.group/u/PierU)\ **Post date:** [January 4, 2023, 4:06pm UTC](https://fortran-lang.discourse.group/t/program-does-not-return-from-deallocate-statement/4975/4 "2023-01-04T16:06:06Z")
How do you know the program hangs in the `deallocate` statement? Running in the debugger? Issues with deallocate often result from a memory overflow somewhere in the code, and it can be tricky to debug… A strategy can be trying deallocating the array earlier and earlier until it “works” (i.e. until the deallocate does what it is supposed to do): this way you can locate where in the code something bad happens. ---
**Author:** ![mEm](https://avatars.discourse-cdn.com/v4/letter/m/90ced4/32.png) [@mEm](https://fortran-lang.discourse.group/u/mEm)\ **Post date:** [January 4, 2023, 4:14pm UTC](https://fortran-lang.discourse.group/t/program-does-not-return-from-deallocate-statement/4975/5 "2023-01-04T16:14:49Z")
@PierU, yes, I run the VS debugger. Also tried the built-in heap allocation tracer, but I didn’t see any useful info coming out of it. Surely, been the very first time I am using it, maybe it’s that I don’t know how to use it. For your suggestion to deallocate them before, I don’t think I can, since the whole procedure logic depends on these allocatables, which are then deallocated at the end. I am afraid, as you say, that spotting it will be much harder than I might think. See the **EDIT 2** for some addition info. I am thinking, if it might help, to directly link (as a Project dependency) my project to LAPACK (i.e. including sources, not just linking to it), so that I can enter with the debugger in it, and see what happens there… ---
**Author:** ![PierU](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/pieru/32/1848_2.png) [@PierU](https://fortran-lang.discourse.group/u/PierU)\ **Post date:** [January 4, 2023, 4:22pm UTC](https://fortran-lang.discourse.group/t/program-does-not-return-from-deallocate-statement/4975/6 "2023-01-04T16:22:48Z")
> [@mEm](#): > > For your suggestion to deallocate it before, I don’t think I can, since the whole procedure logic depend on these allocatables, which are then deallocated at the end. This is for debugging: obviously once deallocated before it should be, the rest of the code won’t work. But at least you can know where the problem is: - move before: it still hangs - move even before: it still hangs - move again before: it doesn’t hang… Then you know that the problem is likely between this location and the previous one. Edit: the real problem is if the allocation/deallocation is inside a loop and the problem is not at the first iteration. The solution is to determine at which iteration it hangs, and deallocate only at this iteration. ---
**Author:** ![mEm](https://avatars.discourse-cdn.com/v4/letter/m/90ced4/32.png) [@mEm](https://fortran-lang.discourse.group/u/mEm)\ **Post date:** [January 4, 2023, 4:24pm UTC](https://fortran-lang.discourse.group/t/program-does-not-return-from-deallocate-statement/4975/7 "2023-01-04T16:24:32Z")
Oh, I see. I’ll try it out and let you know what it gives. Thanks! ---
**Author:** ![mEm](https://avatars.discourse-cdn.com/v4/letter/m/90ced4/32.png) [@mEm](https://fortran-lang.discourse.group/u/mEm)\ **Post date:** [January 4, 2023, 5:00pm UTC](https://fortran-lang.discourse.group/t/program-does-not-return-from-deallocate-statement/4975/8 "2023-01-04T17:00:27Z")
> [@PierU](#): > > Edit: the real problem is if the allocation/deallocation is inside a loop and the problem is not at the first iteration. The solution is to determine at which iteration it hangs, and deallocate only at this iteration. Ok, I have an update. What you suggest cannot be done _directly_, since the loop resides in a ModuleA procedure, while the hanging (called) procedure is in ModuleB (it is actually a type-bound procedure). This would require some logic modification (including sharing the outer-loop index variable, i.e. module variable for example, as well as for the inner-allocated (local) ones, in order to allocate them only once before the loop starts). But, I notice it hangs _always_ (for what I experienced) at the 4th iteration. And it does even placing the deallocations **right after** the allocatiion statements. So? I’m in big trouble, am I? 😃 Still, I wonder how such issue can happen. What might be the causes? Shouldn’t a process know all the memory it holds? How can an allocation “give back” memory which is already in u se? I does not make much sense… ---
**Author:** ![PierU](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/pieru/32/1848_2.png) [@PierU](https://fortran-lang.discourse.group/u/PierU)\ **Post date:** [January 4, 2023, 5:32pm UTC](https://fortran-lang.discourse.group/t/program-does-not-return-from-deallocate-statement/4975/9 "2023-01-04T17:32:38Z")
> [@mEm](#): > > But, I notice it hangs _always_ (for what I experienced) at the 4th iteration. And it does even placing the deallocations **right after** the allocatiion statements. This is bad… Just thinking: - the allocatable object may be corrupted even before allocating it and for some reason the corruption only shows up at the deallocation - or compiler bug? Without a Minimal Working Example (which can be difficult/impossible to provide) it’s difficult to help ---
**Author:** ![NormanKirkby](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/normankirkby/32/1091_2.png) [@NormanKirkby](https://fortran-lang.discourse.group/u/NormanKirkby)\ **Post date:** [January 4, 2023, 6:07pm UTC](https://fortran-lang.discourse.group/t/program-does-not-return-from-deallocate-statement/4975/10 "2023-01-04T18:07:25Z")
Welcome, Can you add STAT= and ERRMSG= clauses to the potentially offending allocate and deallocate statements? The STAT= clause should prevent the program stopping, and the character variable assigned to ERRMSG may or may not contain an explanation. Good luck ---
**Author:** ![mEm](https://avatars.discourse-cdn.com/v4/letter/m/90ced4/32.png) [@mEm](https://fortran-lang.discourse.group/u/mEm)\ **Post date:** [January 4, 2023, 6:13pm UTC](https://fortran-lang.discourse.group/t/program-does-not-return-from-deallocate-statement/4975/11 "2023-01-04T18:13:31Z")
@NormanKirkby , thanks for your answer. Where exactly do you mean? At the `allocate` or `deallocate` statements? I already had the `STAT=` at the `allocate`, and allocation happens successfully, meaning that `stat=` returns `0`. I’ll try at the `deallocate`, adding `ERRMSG=`, though I am afraid it will not give any help once it will have hang… ---
**Author:** ![mEm](https://avatars.discourse-cdn.com/v4/letter/m/90ced4/32.png) [@mEm](https://fortran-lang.discourse.group/u/mEm)\ **Post date:** [January 4, 2023, 6:21pm UTC](https://fortran-lang.discourse.group/t/program-does-not-return-from-deallocate-statement/4975/12 "2023-01-04T18:21:49Z")
> [@PierU](#): > > the allocatable object may be corrupted even before allocating it and for some reason the corruption only shows up at the deallocation Just asking: _could an allocation happen on a corrupted object?_. Shouldn’t the `allocate` statement hang in place of the `deallocate`, or maybe throw an error since all the runtime checks are enabled? I mean, there should be a way to “prevent”, or at least catch these errors. > [@PierU](#): > > Without a Minimal Working Example (which can be difficult/impossible to provide) it’s difficult to help I’d love to provide one, but it’s almost impossible, since it also involves some external dependencies… If you’d be interested, I could show you the _real_ example 🙂 ---
**Author:** ![PierU](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/pieru/32/1848_2.png) [@PierU](https://fortran-lang.discourse.group/u/PierU)\ **Post date:** [January 4, 2023, 8:52pm UTC](https://fortran-lang.discourse.group/t/program-does-not-return-from-deallocate-statement/4975/13 "2023-01-04T20:52:20Z")
> [@mEm](#): > > Just asking: _could an allocation happen on a corrupted object?_. Shouldn’t the `allocate` statement hang in place of the `deallocate`, or maybe throw an error since all the runtime checks are enabled? This is what I would expect too, but who knows… This may depend on what is corrupted precisely. By the way, I would try **removing** the runtime checks, just to see what happens. ---
**Author:** ![mEm](https://avatars.discourse-cdn.com/v4/letter/m/90ced4/32.png) [@mEm](https://fortran-lang.discourse.group/u/mEm)\ **Post date:** [January 5, 2023, 10:29am UTC](https://fortran-lang.discourse.group/t/program-does-not-return-from-deallocate-statement/4975/14 "2023-01-05T10:29:14Z")
> [@NormanKirkby](#): > > The STAT= clause should prevent the program stopping, and the character variable assigned to ERRMSG may or may not contain an explanation. As I was fearing, even placing `STAT=` and `ERRMSG=` to the `deallocate` statements, it did not prevent the program from hanging… ---
**Author:** ![mEm](https://avatars.discourse-cdn.com/v4/letter/m/90ced4/32.png) [@mEm](https://fortran-lang.discourse.group/u/mEm)\ **Post date:** [January 5, 2023, 10:35am UTC](https://fortran-lang.discourse.group/t/program-does-not-return-from-deallocate-statement/4975/15 "2023-01-05T10:35:02Z")
> [@PierU](#): > > By the way, I would try **removing** the runtime checks, just to see what happens. Nothing changes, hangs as usual… ---
**Author:** ![plevold](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/plevold/32/754_2.png) [@plevold](https://fortran-lang.discourse.group/u/plevold)\ **Post date:** [January 5, 2023, 1:21pm UTC](https://fortran-lang.discourse.group/t/program-does-not-return-from-deallocate-statement/4975/16 "2023-01-05T13:21:24Z")
Do you actually need to deallocate manually? If not does the program run fine if you remove the deallocate statement? A local allocatable variable will be deallocated automatically at the end of the scope so no explicit deallocation is needed here: ```auto subroutine sub() integer, allocatable :: arr(:) arr = [1, 2, 3] ! Fortran 2003(?) reallocation semantics allocates the array at this line print *, arr end subroutine ! The array will be deallocated here as the variable goes out of scope ``` If you reuse the variable at a later stage then you definitely need the deallocation and my suggestion won’t work. Example: ```auto integer, allocatable :: arr(:) allocate(arr(2)) arr(1) = 1 arr(2) = 2 print *, arr deallocate(arr) allocate(arr(3) arr(1) = 3 arr(2) = 2 arr(3) = 1 print *, arr ``` There are (at least) two situations where you **should** deallocate in order to avoid memory leaks: 1. When using pointers: ```auto subroutine sub() integer, pointer :: arr(:) allocate(arr(3)) end subroutine ! The variable goes out of scope here, but data will NOT be deallocated since it's a pointer! ``` 1. When using `save`: ```auto subroutine sub() integer, allocatable, save :: arr(:) allocate(arr(3)) end subroutine ! The variable goes out of scope here, but data will NOT be deallocated since it's a saved! ``` Note that legacy code might depend on being compiled with the ifort `-save` which implicitly makes all variables saved even if the keyword `save` doesn’t appear. ---
**Author:** ![RonShepard](https://avatars.discourse-cdn.com/v4/letter/r/a3d4f5/32.png) [@RonShepard](https://fortran-lang.discourse.group/u/RonShepard)\ **Post date:** [January 5, 2023, 7:13pm UTC](https://fortran-lang.discourse.group/t/program-does-not-return-from-deallocate-statement/4975/17 "2023-01-05T19:13:46Z")
> [@plevold](#): > > 1. When using `save`: That is a feature, not a bug. The memory does not “leak”, the array is still there the next time it comes into scope. Its values and all of its attributes (lower and upper bounds, etc.) are all still there, and any external pointers to that array remain valid, even if the array itself is not in scope. [edit:] Just to clarify this a little more the `1. When using pointers:` case **is** a memory leak. Upon return, the pointer is eliminated (its memory on the stack is returned and reused), but the anonymous memory that it pointed to is not deallocated, so even upon subsequent calls to that subroutine, it is no longer possible to access that memory. ---
**Author:** ![plevold](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/plevold/32/754_2.png) [@plevold](https://fortran-lang.discourse.group/u/plevold)\ **Post date:** [January 5, 2023, 7:19pm UTC](https://fortran-lang.discourse.group/t/program-does-not-return-from-deallocate-statement/4975/18 "2023-01-05T19:19:33Z")
Fair point. It’s not a memory leak per se because you can still reach the memory by invoking that procedure again. It is however an exception from the statement I made in the second paragraph about automatic deallocation and does require special care to avoid issues from e.g. calling `allocate` again on that variable. ---
**Author:** ![urbanjost](https://avatars.discourse-cdn.com/v4/letter/u/0ea827/32.png) [@urbanjost](https://fortran-lang.discourse.group/u/urbanjost)\ **Post date:** [January 6, 2023, 2:44am UTC](https://fortran-lang.discourse.group/t/program-does-not-return-from-deallocate-statement/4975/19 "2023-01-06T02:44:05Z")
As has been mentioned, this hints that the hang at the deallocation is a symptom, and that you have corrupted something previously. Do you have a previous version where the problem does not occur? If so, look carefully at the points where you changed the code and look for incorrect calls to procedures and array bound errors. Not everything is detected with array bound checks on. Any procedures with arguments passed to something dimensioned with an asterisk or any calls to something with no explicit interface are the most suspect. Trying with another compiler can often be useful. Add /warn:all and /gen-interfaces on your build(s) if you have a lot of procedures without interfaces and not defined in modules (check the documentation, I do not have it handy; but the sytnax is something like that). These types of bugs can be particularly difficult to debug because the actual corruption probably occurred long before the problem occurs, typically. If you are allocating a number of entities in the procedure and then deallocating them, if possible deallocate them in the opposite order you allocated them and see if that affects when the hang occurs. ---
**Author:** ![JohnCampbell](https://avatars.discourse-cdn.com/v4/letter/j/5daacb/32.png) [@JohnCampbell](https://fortran-lang.discourse.group/u/JohnCampbell)\ **Post date:** [January 6, 2023, 8:34am UTC](https://fortran-lang.discourse.group/t/program-does-not-return-from-deallocate-statement/4975/20 "2023-01-06T08:34:51Z")
@mEm You have not provided any code example of the declaration, allocation and deallocation of the array causing the problem. 1. document allocate I would suggest you expand your code (if not already done) to: ! at allocate IF ( .not. allocated (array) ) then allocate ( array(n,m), stat=stat ) if ( stat==0 ) then write ( _,_) ‘array sucessfully allocated at cycle’, loop\_id else write ( _,_) ‘array failed to allocate at cycle’, loop\_id end if ELSE write ( _,_) ‘array already allocated at cycle’, loop\_id END IF ! at deallocate IF ( allocated (array) ) then deallocate ( array, stat=stat ) ! note using stat= should not hang if ( stat==0 ) then write ( _,_) ‘array sucessfully deallocated at cycle’, loop\_id else write ( _,_) ‘array failed to deallocate at cycle’, loop\_id end if ELSE write ( _,_) ‘array was NOT allocated at cycle’, loop\_id END IF 1. track memory usage looks correct. Using “/check:all” can inhibit the release of memory for debugging, so the allocate/deallocate might not function correctly. I would try to track free memory while the program is running ( eg Task Manager in Win x64 can show free memory changes) Perhaps put a pause at the deallocate so you can monitor the memory for each pass (you stated pass = 4 is a problem?) GlobalMemoryStatusEx is helpful for this in Win x64. There probably are equivalent routines for other OS. ```auto interface function GlobalMemoryStatusEx(mdata) bind(C, name="GlobalMemoryStatusEx") use ISO_C_BINDING !GCC$ ATTRIBUTES STDCALL :: GLOBALMEMORYSTATUSEX logical(C_BOOL) GLOBALMEMORYSTATUSEX integer(C_LONG) mdata(16) end function GlobalMemoryStatusEx end interface ``` 1. Stack corruption The other problem could be an incorrect call to LAPACK, which is corrupting the stack and this becoming evident on return from a previous call before the deallocate. Check the argument lists or utilise INTERFACE checking. Just some ideas that might help. [Next page](https://fortran-lang.discourse.group/t/program-does-not-return-from-deallocate-statement/4975.md?page=2)