- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dear devs,
I am facing a very strange error when trying to deallocate previously allocated variables.
I would have liked being able to post a reproducible example, but what I am working on is a F.E.A. software for which is quite impossible to do it here.
I make my best to let you figure out how strange what happens is, hoping this works out somehow.
Let's imagine a structure ( house, bridge, what you like ) idealised via lines connecting nodes.
Now, given no matter what kind of analysis one would like to perform, we will always end up having Z amount of memory allocation, where Z = X + Y, being X the amount of memory which depends directly to the size of the problem ( size of the structure, etc..), while Y being the memory which depends to external factors, directly or indirectly related to the structure/analysis. Well, X does always change as soon as you change the problem size. This DOES NOT hold always true for Y.
Now, let's put ourselves in the case where Y does not change in extension changing the problem size ( i.e. changing X ). Still, Z always changes.
BUT...
I have this routine to automate in a given way deallocation of memory:
subroutine deleteR( var, name )
implicit none
real, allocatable :: var(..)
character( len = * ) :: name
character( len = 200 ) :: msg
integer :: ist
if ( allocated( var ) ) then
write( iumem , '( /3a )' ), ' ', trim(name), ' is allocated, deallocating..'
deallocate( var, stat=ist, errmsg=msg )
write( iumem, '(a)' ), msg
if ( ist .eq. 0 ) then
write( iumem , '( 3a )' ), ' ', trim(name), ' correctly deallocated.'
else
write( iumem , '( 3a, i4 )' ), ' [ERROR] Cannot deallocate ', trim( name ), '. Exit status ', ist
endif
else
write( iumem , '( 3a )' ), ' ', trim(name), ' is not allocated at this point.'
endif
end subroutine deleteR
In the main routine where ( almost ) all calculations are done ( for this particular type of analysis I am working on ), just after everything has been done, I do proceed to free memory by calling this routine ( well, in reality I call an interface which calls based on the TYPE of the allocatable variable ).
In some cases the problem raises exactly at the line
deallocate( var, stat=ist, errmsg=msg )
having this as last line printed in the output file:
bsa_z_ptref_wind is allocated, deallocating..
That is, not even the status is checked, so I guess is something internally to deallocate() which then turns the %errorlevel% env variable ( Windows x64 OS ) to 241.
But, I was saying that this behavior is shown in a very strage way.
In fact, keeping in mind that we are considering those cases where Y amount of memory remains always the same no matter the problem size, I have this problem when DECREASING the X amount of memory allocation ( i.e. problem size ).
I don't know how this has some sort of sense ( maybe not, I am here to ask for your precious help ), but If it should be a kind of memory corruption error, I would imagine that it is most likely to happen by increasing X, leading to a more likely overlapping between X and Y.
I am sorry for the very long story, but after having checked if I miss something in my allocation/deallocation ( which I couldn't find finally ), I cannot find a reason to this.
I should say, this software dates back to 70s', and it is ( still ) heavily based on the syntax of those times ( i.e. passing the reference to the first element array vs. bounds checking, etc.. )
Thanks to those wild readers that will attempt to find a possible reason, and why not, a solution.
Regards.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
>>Could you explain this statement a little more. I would like to understand it better.
1) allocate an array (with TARGET attribute)
2) define a pointer to this array or slice of this array
3) deallocate the array
4) use the pointer that you defined in step 2
>>PS: one of those three machines was the same as mine. Does it matter ?
Something is likely different. Check what is actually being used on each system (on Windows use Dependency Walker), and any/all pertinent environment variables specifying path, lib, etc... (don't forget to see if you managed to copy a .dll into the app's current directory).
Note, if this is a flaky memory issue, you would likely see problems elsewhere too. To test, power down, remove memory sticks, wipe with isopropyl alcohol ... insert in different order. If problem persists as before, this is most likely programming error.
Jim Dempsey
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This seems related to this: https://community.intel.com/t5/Intel-Fortran-Compiler/quot-forrtl-severe-151-allocatable-array-is-already-allocated/m-p/1291096#M156403
In that case, it was memory corruption caused by a programming error.
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I do not see the X Y Z discussion being that relevant. A deallocate just frees up a specified memory range. So as Jim says if that fails then it is the result of some other cause that has already foo-bahed a memory table maybe. As a laugh do a test deallocate immediately after the allocate and see the result of that. Maybe a few such calls might find a zone in the program where things do wrong but it maybe an heisenbug so it will not help much.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
What does errmsg=msg lead to? What is in 'msg'?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Nothing at all. As said, that line is the very last line printed in the output file.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@jimdempseyatthecove , @andrew_4619 nice suggestions, but, I let other three machines test the SAME .exe I generated ( with the same input file ).
All three machines had no error at all.
I am starting to think that my PC's memory has some issues ( in some specific places on the vertices, I start to feel some little shook, as if there are some electricity leaks in the system ).
To be clear, it is still possible that some programming errors are there, but three machines that run nicely are more than a mere casuality.
What do you think?
Regards.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
>>I let other three machines test the SAME .exe I generated ( with the same input file ).
Variations in memory capacity from system to system can lead to placement differences of heap allocations. IIF the error is cause by writing beyond end of bounds .OR. using a POINTER who's define state is no longer in effect (iow was defined to be that of an allocatable array or array section that had been subsequently reallocated or reallocated). Note, the newer compiler versions default is standard-realloc-lhs meaning an allocatable array on left hand side of an expression, depending on right hand side expression, may be implicitly reallocated. (Documentation regarding standard-realloc-lhs does not state if allocatable arrays with TARGET attribute are excluded from reallocation), and should you create a pointer to this array (or slice of the array), then any/all pointers pointing to the array (slice) are no longer valid (but will not issue an error should you dereference what it used to point to).
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dear @jimdempseyatthecove , first of all thanks for the precious reply.
>>.OR. using a POINTER who's define state is no longer in effect (iow was defined to be that of an allocatable array or array section that had been subsequently reallocated or reallocated).
Could you explain this statement a little more. I would like to understand it better.
Anyway, I don't think it is the case, since for this kind of computation I am not using any POINTER or ALLOCATABLE, TARGET.
So only writing out of bounds remains as feasible option ?
PS: one of those three machines was the same as mine. Does it matter ?
Regards,
Michele
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
>>Could you explain this statement a little more. I would like to understand it better.
1) allocate an array (with TARGET attribute)
2) define a pointer to this array or slice of this array
3) deallocate the array
4) use the pointer that you defined in step 2
>>PS: one of those three machines was the same as mine. Does it matter ?
Something is likely different. Check what is actually being used on each system (on Windows use Dependency Walker), and any/all pertinent environment variables specifying path, lib, etc... (don't forget to see if you managed to copy a .dll into the app's current directory).
Note, if this is a flaky memory issue, you would likely see problems elsewhere too. To test, power down, remove memory sticks, wipe with isopropyl alcohol ... insert in different order. If problem persists as before, this is most likely programming error.
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@jimdempseyatthecove , it was apparently a programming error.
Thanks to everyone that answered to this topic !
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page