Debugging functional in VS 2015 + IPS XE 2017 U2 causes exception in VS 2019 + IPS XE 2020

[jirina]

I am switching from IPS XE 2017 Update 2 (integrated to VS 2015 Pro) to IPS XE 2020 Initial Release (integrated to VS 2019 Pro). I made a copy of the solution/project for my console application, opened the copy in VS 2019 and started debugging. At a certain location in the code, exception is thrown, saying "MyApp.exe has triggered a breakpoint.", without any details. In the Call Stack window, I can see the corresponding source code line and two more lines above it, saying "libifcoremdd.dll!00007ffe3fdb737c() Unknown" and "libifcoremdd.dll!00007ffe3fdb68ff() Unknown" (Unknown is in the column Language). If I am debugging the very same code in VS 2015 + IPS XE 2017, there is no exception thrown and everything works well. Running Release versions compiled by both IPS versions is OK too; everything works as expected. So the only problem is that I cannot debug my application in VS 2019.

I tried several things, one by one, but they might be unrelated to the issue I am having:

• I changed Fortran -> Libraries -> Runtime Library from Debug Multithread DLL (/libs:dll) to Debug Multithreaded (/libs:static). After this change, VS 2019 runs my application in the debug mode, but does not reach any breakpoint, crashes and restarts.
• I increased Linker -> System -> Stack Reserve Size from 100 000 000 to 1 000 000 000. Before this change, VS 2019 did not even hit the breakpoint placed at the location of the thrown exception; VS 2019 closed and re-started!
• It is not possible to go higher with stack reserve size and I found an explanation for this by Steve Lionel here.

I am using 3D arrays in my application and total memory used is several GB, less than 5 GB in this specific case. A single double precision 3D array with 12 million elements uses roughly 100 MB of memory.

If I try debugging a case with smaller 3D arrays, I get the exception too, so it does not seem to be cause by the total memory usage of my application. For this case, it was not needed to increase the stack reserve size to prevent VS from crashing before hitting the breakpoint.

My application is 64-bit, these are compiler and linker settings of the Debug configuration:

/nologo /debug:full /MP /Od /I"%MKLROOT%" /I"\include" /fixed /extend_source:132 /Qopenmp /fpscomp:general /Qdiag-disable:8290,8291,5462 /warn:declarations /warn:truncated_source /warn:noalignments /warn:interfaces /assume:byterecl /module:"x64\Debug\\" /object:"x64\Debug\\" /Fd"x64\Debug\vc160.pdb" /traceback /check:pointer /check:bounds /check:uninit /check:format /check:output_conversion /check:arg_temp_created /check:stack /libs:dll /threads /dbglibs /Qmkl:parallel /c

/OUT:"x64\Debug\MyApp.exe" /INCREMENTAL:NO /NOLOGO /DELAYLOAD:"MyApp64.dll" /MANIFEST /MANIFESTFILE:"x64\Debug\MyApp.exe.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG /PDB:"...\x64\Debug\Vitreous.pdb" /SUBSYSTEM:CONSOLE /STACK:1000000000 /IMPLIB:"...\x64\Debug\Vitreous.lib" delayimp.lib ..\DLL\x64\MyAppx64.lib mkl_intel_lp64_dll.lib mkl_intel_thread_dll.lib mkl_core_dll.lib libiomp5md.lib

What should I do to make debugging work in VS 2019 + IPS XE 2020 IR ?

[jirina]

I found the cause of the problem immediately after i posted my questions. :-)

I am calling a subroutine and some arguments are allocatable arrays that are not allocated at the moment of the call. In IPS 2017, the called subroutine does not declare these arrays as allocatable since I am not changing their allocation state. In IPS 2020, I declared them as allocatable in the called subroutine and things work well as expected.

I am sorry if anyone spent time reading my original post and investigating the issue; I did not find a way how to delete my original post.

[Steve_Lionel]

Simply adding ALLOCATABLE should not have an effect, assuming that the arrays had assumed-shape (:) and that an explicit interface was visible to the caller.

[jirina]

I simplified the structure of modules to demonstrate what I am trying to do:

      module MatrixSolverFlowFields
	  
	  integer(4), allocatable, dimension(:) :: iVec_u, jVec_u
	  
	  end module MatrixSolverFlowFields
	  
	  ! -------------------------------------------------------------
	  
	  module MatrixSolverFlow
	  contains
	  
	  subroutine solveVelocityComponentU
	  use MatrixSolverFlowFields
	  logical(1) : isStaggered
	  integer(4) :: status
	  
	  isStaggered = .true.
	  status = initializeMatrixSolver ( iVec_u, jVec_u, isStaggered )
	  
	  end subroutine solveVelocityComponentU
	  
	  end module MatrixSolverFlow
	  
	  ! -------------------------------------------------------------
	  
	  module MatrixSolverSparse
	  contains
	  
	  integer(4) function initializeMatrixSolver ( iVec, jVec, isStaggered )
	  integer(4), allocatable, dimension(:) :: iVec, jVec
	  logical(1) :: isStaggered, getDimensionsOnly
	  
	  getDimensionsOnly = .true.
	  call constructMatrix ( iVec, jVec, isStaggered, getDimensionsOnly )
	  
	  ! iVec, jVec are allocated here after dimensions are obtained above
	  
	  getDimensionsOnly = .false.
	  call constructMatrix ( iVec, jVec, isStaggered, getDimensionsOnly)
	  
	  end function initializeMatrixSolver
	  
	  subroutine constructMatrix ( iVec, jVec, isStaggered, getDimensionsOnly )
	  integer(4), dimension(:) :: iVec, jVec
	  logical(1) :: isStaggered, getDimensionsOnly
	  
	  if ( isStaggered ) then
	    call constructMatrixStaggered ( iVec, jVec, getDimensionsOnly )
	  else
	    ...
	  endif
	  
	  end subroutine constructMatrix
	  
	  subroutine constructMatrixStaggered ( iVec, jVec, getDimensionsOnly )
	  integer(4), dimension(:) :: iVec, jVec
	  logical(1) :: getDimensionsOnly
	  
	  if ( getDimensionsOnly ) then
	    ...
	  else
	    iVec = ...
		jVec = ...
	  endif
	  
	  end subroutine constructMatrixStaggered
	  
	  end module MatrixSolverSparse

This worked well in IPS XE 2017 U2 debugger when stepping into constructMatrix and crashed in IPS XE 2020. After adding ALLOCATABLE to constructMatrix{Staggered}, debugging in IPS XE 2020 does not crash anymore. Does this make sense?