Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
This community is designed for sharing of public information. Please do not share Intel or third-party confidential information here.

DEALLOCATE() returns 241 exit code

mic_esp96
Novice
882 Views

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.

Labels (2)
0 Kudos
1 Solution
jimdempseyatthecove
Black Belt
766 Views

>>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

 

View solution in original post

9 Replies
jimdempseyatthecove
Black Belt
842 Views

This seems related to this: https://community.intel.com/t5/Intel-Fortran-Compiler/quot-forrtl-severe-151-allocatable-array-is-al...

 

In that case, it was memory corruption caused by a programming error.

Jim Dempsey

andrew_4619
Honored Contributor I
833 Views

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.

FortranFan
Honored Contributor II
818 Views

What does errmsg=msg lead to?  What is in 'msg'?

mic_esp96
Novice
815 Views

Nothing at all. As said, that line is the very last line printed in the output file.

mic_esp96
Novice
814 Views

@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.

jimdempseyatthecove
Black Belt
792 Views

>>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

mic_esp96
Novice
773 Views

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

jimdempseyatthecove
Black Belt
767 Views

>>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

 

mic_esp96
Novice
725 Views

@jimdempseyatthecove , it was apparently a programming error.

 

Thanks to everyone that answered to this topic !

Reply