Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
27523 Discussions

forrtl: severe (122): invalid attempt to assign into a pointer that is not associated.

krefson
Beginner
521 Views
I am encountering a mysterious diagnostic forrtl: severe (122): invalid attempt to assign into a pointer that is not associated. in a rather large Fortran code on which I develop. It is mysterious because no pointers are involved. The abort line from the traceback is 656 current_sedc = sedc_calc where "current_sedc" and "sedc_calc" are instances of a straightforward derived type containing small arrays and allocatable arrays of intrinsic types, logical, real, integer and character. No pointers, derived type components, classes, parameterization or anything fancy. current_sedc is a module-level declaration with the "save" attribute, and "sedc_calc" is a subroutine-scope declaration in the same scope as the assignment statement. This error only occurs with very recent versions of both ifort and ifx, 2021.7.0 and 2021.7.1 (in oneAPI releases 2022.2.0 and 2022.2.1), and no abort was seen in any earlier version. It occurs at all optimization and debug levels. Furthermore it does not occur with any of the other four different Fortran compilers I have tried. Therefore I suspect a compiler bug. It's a very large code, and unfortunately my attempts to boil down to a reproducible test case have failed. The only other diagnostic I have been able to obtain is a valgrind trace ==3441== Conditional jump or move depends on uninitialised value(s) ==3441== at 0x588A8CF: do_alloc_assign (in ) ... ==3441== Use of uninitialised value of size 8 ==3441== at 0x588A938: do_alloc_assign (in ) ... ==3441== Invalid read of size 8 ==3441== at 0x588A938: do_alloc_assign (in ) all at the call site reported by the diagnostic. By contrast, if I compile using 2022.1.0 and run under valgrind the run completes with no such diagnostics. Any suggestions of how to proceed will be welcome. As I wrote above, the failure occurs only in the context of the whole program, and my efforts to encapsulate the offending code in a smaller example do not reproduce the issue. Keith Refson
0 Kudos
9 Replies
krefson
Beginner
511 Views

Apologies - completely botched the formatting there.

 

I am encountering a mysterious diagnostic
forrtl: severe (122): invalid attempt to assign into a pointer that is not associated. 
in a rather large Fortran code on which I develop. It is mysterious because no pointers are involved. The abort line from the traceback is
656 current_sedc = sedc_calc 
where "current_sedc" and "sedc_calc" are instances of a straightforward derived type containing small arrays and allocatable arrays of intrinsic types, logical, real, integer and character. No pointers, derived type components, classes, parameterization or anything fancy. current_sedc is a module-level declaration with the "save" attribute, and "sedc_calc" is a subroutine-scope declaration in the same scope as the assignment statement.
This error was introduced with recent versions of both ifort and ifx, 2021.7.0 and 2021.7.1 (in oneAPI releases 2022.2.0 and 2022.2.1), and no abort was seen in any earlier version. It occurs at all optimization and debug levels. Furthermore it does not occur with any of the other four different Fortran compilers I have tried. Therefore I suspect a compiler bug.
It's a large code, and unfortunately my attempts to boil down to a reproducible test case have failed. The only other diagnostic I have been able to obtain is a valgrind trace
==3441== Conditional jump or move depends on uninitialised value(s) 
==3441== at 0x588A8CF: do_alloc_assign (in )
...
==3441== Use of uninitialised value of size 8
==3441== at 0x588A938: do_alloc_assign (in )
...
==3441== Invalid read of size 8
==3441== at 0x588A938: do_alloc_assign (in )
...
all at the call site reported by the diagnostic. By contrast, if I compile using 2022.1.0 and run under valgrind the run completes with no such diagnostics.
Any suggestions of how to proceed will be welcome. As I wrote above, the failure occurs only in the context of the whole program, and my efforts to encapsulate the offending code in a smaller example do not reproduce the issue.
Keith Refson
FortranFan
Honored Contributor II
496 Views

@krefson ,

Since you write, "It occurs at all optimization and debug levels," I suggest you try your code with /check:all toward Intel Fortran run-time checking under Debug model (F5 key) in Microsoft Visual Studio on Windows OS if you're able to.

In many instances, the Visual Studio debugger traps the run-time exception right where it occurs and it shows you the code and the line where the exception got triggered and usually also the stack trace and the state and values of objects at the time of the exception.  You can then try to work your way backward to try to determine the events that led to the exception.

Good luck,

 

krefson
Beginner
183 Views

I did test this with full run-time checking on, and there is no difference in behaviour.  The run is aborted by the RTL with

forrtl: severe (122): invalid attempt to assign into a pointer that is not associated. 

at exactly the same line, namely 

current_sedc = sedc_calc 

where both LHS and RHS are define types without a pointer in sight.  The types do contain allocatables though, but I believe the standard allows for assignment of a type containing an unallocated allocatable.

jimdempseyatthecove
Black Belt
494 Views

>>current_sedc is a module-level declaration with the "save" attribute

Is this in the data portion of the module or in a contained procedure of the module?

 

Can you show the declaration of current_sedc and show the type declaration for current_sedc's type.

Note, if current_sedc is located in the data portion of the module then the SAVE attribute is not warranted. (It would be if in a contained procedure).

 

The error message implies that current_sedc (at location of offending statement) is a pointer as opposed to an object.

Is current_sedc declared in the scope of the offending statement in addition to within the module used? (iow superseding module's declaration)

 

Jim Dempsey

krefson
Beginner
182 Views

With lots of detail elided, this looks like

module dftd
   <other module use statements>
   use dftd_utils,only : sedc_calculation
   type(sedc_calculation), save  :: current_sedc

contains
   subroutine  sedc_calculate_properties (cell_in)
      use dftd_utils,  
      type(unit_cell), intent(in) :: cell_in
 
      type(sedc_calculation)      :: sedc_calc

       < compuation code which populates "sedc_calc" >

      current_sedc = sedc_calc ! <====== Abort happens on this line

   end subroutine  sedc_calculate_properties
end module dftd
module dftd_utils
  !Bunch of constants required for unit conversion......
  use constants

  implicit none
  private

  !This is used to store the results of a calculation
  type, public :: sedc_calculation

     !Scheme name
     integer                    :: Scheme = Not_Assigned
     character(len=10)          :: schemeStr

     !XC functional name
     character(len=10)          :: xc_functional

     !Unit cell info
     integer                    :: num_ions
     real(kind=dp)              :: real_lattice(3,3)
     real(kind=dp)              :: recip_lattice(3,3)
     real(kind=dp)              :: cell_volume

     !Periodic table with custom species
     integer                       :: periodic_table_size
     character(len=8), allocatable :: periodic_table(:)

     !Species info (for cross checking)
     integer                    :: num_species
     integer,          allocatable :: species_Z(:)
     character(len=8), allocatable :: species_symbol(:)
     integer,          allocatable :: species_base(:)

     
     !Atom information
     real(kind=dp), allocatable :: frac_positions(:,:)
     real(kind=dp), allocatable :: cart_positions(:,:)
     integer,       allocatable :: ion_Z(:)

     !Some extra info
     integer,       allocatable :: num_plane_waves_kp(:)

     !Results from dispersion methods
     real(kind=dp)              :: energy
     real(kind=dp)              :: stress(6)
     real(kind=dp), allocatable :: forces(:,:,:)

     !Flags to say whether we have these quantities
     logical                    :: have_energy = .false.
     logical                    :: have_forces = .false.
     logical                    :: have_stress = .false.

     !Flags to say whether we want these quantities
     logical                    :: need_energy = .false.
     logical                    :: need_forces = .false.
     logical                    :: need_stress = .false.

     !Tolerances for convergence of energy,forces,stress
     real(kind=dp)              :: energy_tol
     real(kind=dp)              :: forces_tol
     real(kind=dp)              :: stress_tol

     !Terms for TS method
     logical                    :: have_ts_ratios = .false.
     logical                    :: need_ts_ratios = .false.
     real(kind=dp), allocatable :: TS_ratios(:)

     !Some derivatives for stress
     real(kind=dp), dimension(3,3)   :: volume_deriv          !Derivative of volume WRT lattice matrix
     real(kind=dp), dimension(3,3)   :: recip_lattice_deriv   !Change in reciprocal lattice matrix WRT real lattice

     !Must store the custom param string to check if these have changed
     character(len=file_maxpath),dimension(:),allocatable ::sedc_custom_params

     !Some finite derivative points                                                                      
     integer                    :: fd_num_steps
     real(kind=dp)              :: fd_step_size
     real(kind=dp), allocatable :: fd_coeffs(:)

     !SCS parameters
     logical                    :: have_scs=.false. !Have we saved the scs parameters already?
     real(kind=dp), allocatable :: scs_c6(:)    !scs c6 parameters (per ion)
     real(kind=dp), allocatable :: scs_r0(:)    !scs r0 parameters (per ion)
     real(kind=dp), allocatable :: scs_alpha(:) !scs alpha parameters (per ion)

     !MBD Range parameters
     logical                         :: mbd_range_custom ! Custom range parameters
     real(kind=dp)                   :: mbd_pair_range   ! Maximum pairwise interaction distance
     real(kind=dp)                   :: mbd_tensor_range   ! Maximum range for coupled VdW modes
     
     !Verbosity level
     integer                    :: iprint

     !Debug output devel flag
     logical                    :: debug_output
     
  end type sedc_calculation
contains
 <routenes elided>
end module dftd_utils

 


@krefson wrote:
I am encountering a mysterious diagnostic forrtl: severe (122): invalid attempt to assign into a pointer that is not associated. in a rather large Fortran code on which I develop. It is mysterious because no pointers are involved. The abort line from the traceback is 656 current_sedc = sedc_calc where "current_sedc" and "sedc_calc" are instances of a straightforward derived type containing small arrays and allocatable arrays of intrinsic types, logical, real, integer and character. No pointers, derived type components, classes, parameterization or anything fancy. current_sedc is a module-level declaration with the "save" attribute, and "sedc_calc" is a subroutine-scope declaration in the same scope as the assignment statement. This error only occurs with very recent versions of both ifort and ifx, 2021.7.0 and 2021.7.1 (in oneAPI releases 2022.2.0 and 2022.2.1), and no abort was seen in any earlier version. It occurs at all optimization and debug levels. Furthermore it does not occur with any of the other four different Fortran compilers I have tried. Therefore I suspect a compiler bug. It's a very large code, and unfortunately my attempts to boil down to a reproducible test case have failed. The only other diagnostic I have been able to obtain is a valgrind trace ==3441== Conditional jump or move depends on uninitialised value(s) ==3441== at 0x588A8CF: do_alloc_assign (in ) ... ==3441== Use of uninitialised value of size 8 ==3441== at 0x588A938: do_alloc_assign (in ) ... ==3441== Invalid read of size 8 ==3441== at 0x588A938: do_alloc_assign (in ) all at the call site reported by the diagnostic. By contrast, if I compile using 2022.1.0 and run under valgrind the run completes with no such diagnostics. Any suggestions of how to proceed will be welcome. As I wrote above, the failure occurs only in the context of the whole program, and my efforts to encapsulate the offending code in a smaller example do not reproduce the issue. Keith Refson

> The error message implies that current_sedc (at location of offending statement) is a pointer as opposed to an object.

 

The error message is clearly wrong.

Hope this clarifies.

K.

jimdempseyatthecove
Black Belt
174 Views

I made a test program from your code above. A few edits were necessary to get it to compile. This program compiles and runs OK using oneAPI ifort, and oneAPI ifx version 2022.1.0.256 x64 build Debug and Release configuration.

 

 

!  krefson.f90 
module constants
    integer, parameter :: dp = SELECTED_REAL_KIND(13)
    integer, parameter :: file_maxpath = 512
    integer, parameter :: Not_Assigned = Z'80000000'    ! a.k.a. -0
end module constants
    
module dftd_utils
  !Bunch of constants required for unit conversion......
  use constants

  implicit none
  private
  
  type, public :: unit_cell
      real(kind=dp) :: mass
  end type unit_cell
  

  !This is used to store the results of a calculation
  type, public :: sedc_calculation

     !Scheme name
     integer                    :: Scheme = Not_Assigned
     character(len=10)          :: schemeStr

     !XC functional name
     character(len=10)          :: xc_functional

     !Unit cell info
     integer                    :: num_ions
     real(kind=dp)              :: real_lattice(3,3)
     real(kind=dp)              :: recip_lattice(3,3)
     real(kind=dp)              :: cell_volume

     !Periodic table with custom species
     integer                       :: periodic_table_size
     character(len=8), allocatable :: periodic_table(:)

     !Species info (for cross checking)
     integer                    :: num_species
     integer,          allocatable :: species_Z(:)
     character(len=8), allocatable :: species_symbol(:)
     integer,          allocatable :: species_base(:)

     
     !Atom information
     real(kind=dp), allocatable :: frac_positions(:,:)
     real(kind=dp), allocatable :: cart_positions(:,:)
     integer,       allocatable :: ion_Z(:)

     !Some extra info
     integer,       allocatable :: num_plane_waves_kp(:)

     !Results from dispersion methods
     real(kind=dp)              :: energy
     real(kind=dp)              :: stress(6)
     real(kind=dp), allocatable :: forces(:,:,:)

     !Flags to say whether we have these quantities
     logical                    :: have_energy = .false.
     logical                    :: have_forces = .false.
     logical                    :: have_stress = .false.

     !Flags to say whether we want these quantities
     logical                    :: need_energy = .false.
     logical                    :: need_forces = .false.
     logical                    :: need_stress = .false.

     !Tolerances for convergence of energy,forces,stress
     real(kind=dp)              :: energy_tol
     real(kind=dp)              :: forces_tol
     real(kind=dp)              :: stress_tol

     !Terms for TS method
     logical                    :: have_ts_ratios = .false.
     logical                    :: need_ts_ratios = .false.
     real(kind=dp), allocatable :: TS_ratios(:)

     !Some derivatives for stress
     real(kind=dp), dimension(3,3)   :: volume_deriv          !Derivative of volume WRT lattice matrix
     real(kind=dp), dimension(3,3)   :: recip_lattice_deriv   !Change in reciprocal lattice matrix WRT real lattice

     !Must store the custom param string to check if these have changed
     character(len=file_maxpath),dimension(:),allocatable ::sedc_custom_params

     !Some finite derivative points                                                                      
     integer                    :: fd_num_steps
     real(kind=dp)              :: fd_step_size
     real(kind=dp), allocatable :: fd_coeffs(:)

     !SCS parameters
     logical                    :: have_scs=.false. !Have we saved the scs parameters already?
     real(kind=dp), allocatable :: scs_c6(:)    !scs c6 parameters (per ion)
     real(kind=dp), allocatable :: scs_r0(:)    !scs r0 parameters (per ion)
     real(kind=dp), allocatable :: scs_alpha(:) !scs alpha parameters (per ion)

     !MBD Range parameters
     logical                         :: mbd_range_custom ! Custom range parameters
     real(kind=dp)                   :: mbd_pair_range   ! Maximum pairwise interaction distance
     real(kind=dp)                   :: mbd_tensor_range   ! Maximum range for coupled VdW modes
     
     !Verbosity level
     integer                    :: iprint

     !Debug output devel flag
     logical                    :: debug_output
     
  end type sedc_calculation
contains
! <routenes elided>
    end module dftd_utils

module dftd
!   <other module use statements>
   use dftd_utils,only : sedc_calculation
   type(sedc_calculation), save  :: current_sedc

contains
   subroutine  sedc_calculate_properties (cell_in)
      use dftd_utils  
      type(unit_cell), intent(in) :: cell_in
 
      type(sedc_calculation)      :: sedc_calc

!       < compuation code which populates "sedc_calc" >

      current_sedc = sedc_calc ! <====== Abort happens on this line
        print *,"ok"
   end subroutine  sedc_calculate_properties
end module dftd
    

program krefson
    use dftd_utils
    use dftd
    implicit none
    type(unit_cell) :: cell
    call sedc_calculate_properties (cell)
    print *,"done"
end program krefson

Can you see if this "reproducer" fails on your system.

 

Jim Dempsey

 

krefson
Beginner
172 Views

Your test program succeeds on my system, as I anticipated - my own attempt at extracting a reproducible case did allocate most of the arrays in the type too.

By the way, your test system 2022.1.0 would have succeed even for the full program, as that is not the version which fails.  The failure occurs only with 2022.2.0 and 2022.2.1.

K.

jimdempseyatthecove
Black Belt
165 Views

I have not installed 2022.2.0 nor 2022.2.1 as the improvements for ifort/ifx were not significant (as they were for C++).

With 2023 weeks away, I will await until then to update.

 

Jim Dempsey

krefson
Beginner
134 Views

Now that 2023.0.0 has arrived, I have it a spin with the latest version, and the test run completes successfully.

I will update the compile notes for our users to avoid the 2022.2 versions of ifort as buggy.

K.

 

Reply