Debugger hangs when stepping over an intrinsic function

[Samuel_D_]

Hello all, Aside the annoying issue with the .pdb file that get locked most of the time when the debug session is stopped manually (that can be workaround with sysinternals handle.exe tool), I have a problem with the debugger that hangs randomly when an intrinsic function (like allocate, minloc) is stepped over. The debugger indicates "Running" and the execution of the intrinsic takes forever. It does not depend on the size of the arrays given in parameter to the intrinsic. The only solution I have found is to break the debugger ("Break All"), move the cursor to the next line and then "Continue to cursor". Is it a know issue ? Is there a workaround ? Visual Studio 2012 Update 4 Intel(R) Composer XE 2013 SP1 Update 2 (package 176)

[pbkenned1]

Hello Samuel,

I'll look into if it's a known issue, but I can't reproduce your issue with a small example from the Fortran User's Guide:

PROGRAM U507061
INTEGER i, minl(1)
INTEGER array(2, 3)
INTEGER, ALLOCATABLE :: AR1(:)
! put values in array
array = RESHAPE((/-7, 1, -2, -9, 5, 0/),(/2, 3/))
!   array is   -7 -2 5
!               1 -9 0
i = SIZE(SHAPE(array))  ! Get the number of dimensions in array
ALLOCATE (AR1 (i) )     ! Allocate AR1 to number of dimensions in array
AR1 = MINLOC (array, MASK = array .GT. -5) ! Get the                        
! location (subscripts) of smallest element greater than -5 in array
!
! MASK = array .GT. -5 creates a mask array the same
! size and shape as array whose elements are .TRUE. if
! the corresponding element in array is greater than
! -5, and .FALSE. if it is not. This mask causes MINLOC
! to return the index of the element in array with the
! smallest value greater than -5.
!
!array is  -7 -2 5 and MASK= array .GT. -5 is  F T T
!           1 -9 0                             T F T
! and AR1 = MINLOC(array, MASK = array .GT. -5) returns
! (1, 2), the location of the element with value -2
minl = MINLOC((/-7,2,-7,5/))  
print *,'minl =',minl
! returns 1, first occurrence of minimum
END PROGRAM U507061

I did a 32-bit Debug build with ifort-Version 14.0.2.176, using VS2012.  Set breakpoints on the ALLOCATE, first MINLOC, and last MINLOC.  Ran to each breakpoint, then pressing F10 to step over does so without delay.

Perhaps you could attach a reproducer?

Thanks,

patrick

[Samuel_D_]

Hello Patrick, The thing is that the issue is quite unpredictable, by that I mean i does not always happen with a given code. It seems to happen with any intrinsic but I see it mostly with "allocate". Could you try to set the break point a line upper the call to allocate and then step over ? I will try to isolate the problem. In the meantime, is there anything I can look at when that happens again that could help you track this issue ? I have encountered an other, probably unrelated issue : my current build used to crash at runtime with a severe (41) error. A complete rebuild of the solution only has solved the problem. The thing is that, for visual studio, the executable was up to date (and so a rebuild was not necessary). Is there any chances that obj and mod file could get out of phase or something like this ? I have a hard time understanding how a complete rebuild of a given f90 code could "fix" a runtime error... Regards, Samuel

[pbkenned1]

Hello Samuel,

I understand the problem is intermittent.  I've tried running my example over and over in the debugger, but the problem won't reproduce, regardless of where I set a breakpoint.  Perhaps it is too much of a toy program, so I will look forward to something more real world from you.

What happens if you try 'step into', instead of 'step over'?  I get essentially the same behaviour for either command, but perhaps 'step into' will be a workaround for you.

I don't have a good answer as to why a 'complete rebuild' would fix a runtime error, if nothing was out-of-date.  When your build crashes, are you running the executable within Visual Studio?  If you do a Visual Studio build, then exit Visual Studio, then restart Visual Studio and run the executable (without doing a rebuild), does it still crash?

patrick

[jimdempseyatthecove]

Samuel,

As a work around, when at intrinsic you can right-click on next statement and pick Run to Cursor.

I haven't experienced that problem.

Jim Dempsey

[Steven_L_Intel1]

allocate is a statement, not a function - it shouldn't cause any issues, I could imagine that if you call an elemental function on a large array, and do a Step Over, this translates into a loop over the array and potentially lots of instructions, each of which the debugger single-steps over until the line number changes.

[Bernard]

Maybe the problem is related to pdb file or to the opcode parsing?

[Samuel_D_]

@Jim, yes that is what I use to do (as mentioned in my original post) ! But that's not really convenient. @Steve, thanks for the distinction between statement and function, the Fortran jargon is still a bit foreign to me. Candid question : does that really matters for the debugger ? The size of the arrays given in parameters to function seems not to matter (minloc with an array of size = 2 can hang the debugger when stepped over). In the other hand,if I step over the intrinsic using Jim's advice, the execution is instant. Note that it happens in debug builds where all optimizations are turned off. @Patrick, that sounds weird to step into a statement or an intrinsic function, but I'll give it a try ant let you know ! My colleague, who has a similar setup, does experience the same issue. The code we are working on makes an extensive use of deferred-length character types. The reason I mention this is that I know from experience that gfortran is quite "sensitive" to this quite new feature. About the other issue (the one that was fixed with a complete rebuild), I'm wondering if compiling a single file (Ctrl+F7) could interfere with the build system (files that should have been recompiled are not) ? Yesterday this issue has been experienced by my colleague to ! Regards, Samuel

[Steven_L_Intel1]

If the debugger is hanging on a minloc with array size of 2, then something unusual is going on. This isn't something I've seen reported elsewhere, though.

[jimdempseyatthecove]

minloc may "hang" when array bounds checking is enabled and the array is large. Small arrays the hang time might be short.

Same issue for any array operation:
Array = Array * Scalar

(in the above case, subscripts need not be checked but they are or used to be checked)

Jim Dempsey

[FortranFan]

Samuel D. wrote:

Hello all, Aside the annoying issue with the .pdb file that get locked most of the time when the debug session is stopped manually (that can be workaround with sysinternals handle.exe tool), I have a problem with the debugger that hangs randomly when an intrinsic function (like allocate, minloc) is stepped over. The debugger indicates "Running" and the execution of the intrinsic takes forever. It does not depend on the size of the arrays given in parameter to the intrinsic. The only solution I have found is to break the debugger ("Break All"), move the cursor to the next line and then "Continue to cursor". Is it a know issue ? Is there a workaround ? Visual Studio 2012 Update 4 Intel(R) Composer XE 2013 SP1 Update 2 (package 176)

Are you doing mixed-mode debugging where both managed memory applications (e.g., Microsoft's .NET) and unmanaged memory applications/libraries (e.g., conventional C, C++, Fortran code) are involved?  If so, it is a known issue that Visual Studio 2012 (and 2013) debugger executes very slowly which can appear as "hanging" - this has nothing to do with Fortran or Intel's integration with VS.

Have you tried Visual Studio 2010 instead?  You can use the same version of Intel Fortran that you're currently using.

I've both Visual Studio 2010 and 2012 running side-by-side in my environment and for mixed-mode applications, I do all my debugging using Visual Studio 2010.  For the same set of code built with the same Fortran, C, C++ libraries and the same .NET Framework and assembler for C#, Visual Basic stuff, debugging in VS2010 sees no lags but it is a real pain to step-through in VS2012.

[Bernard]

@Samuel

When debugger hangs you can use Process Explorer to observe the busy thread and its call stack.It could give a crude estimation on what hogs the CPU.

[Samuel_D_]

It's a pure Fortran application, no .Net involved. I don't have VS 2010 available, but I should have VS 2013 in the next weeks... The hang seems intermittent but can be easily reproduce on my setup. A step over an allocate statement gives a CPU jum to 100% on one core (Process: devenv.exe more specifically vsdebugeng.impl.DLL). The stack is : usp10.dll+0x8580 VSDebugEng.dll!DkmDisplayRetailAssert+0x1148 VSDebugEng.dll!ProcFFE7BBBBC1EC94B9CB3791B48190C3C2+0x252c1 VSDebugEng.dll!ProcFFE7BBBBC1EC94B9CB3791B48190C3C2+0x2185a VSDebugEng.dll!ProcFFE7BBBBC1EC94B9CB3791B48190C3C2+0x22b73 VSDebugEng.dll!ProcFFE7BBBBC1EC94B9CB3791B48190C3C2+0x21c75 VSDebugEng.dll!ProcFFE7BBBBC1EC94B9CB3791B48190C3C2+0x2342f VSDebugEng.dll!DkmDllEnsureInitialized+0x7814b VSDebugEng.dll!ProcDkmGetExtendedPart+0x10c2 VSDebugEng.dll!DkmDllEnsureInitialized+0x77e00 vsdebugeng.impl.DLL!ImplDllCreateInstance+0x799e2 VSDebugEng.dll!DkmDllEnsureInitialized+0x77e00 vsdebugeng.impl.DLL!ImplDllCreateInstance+0x7821a vsdebugeng.impl.DLL!ImplDllCreateInstance+0x70c36 vsdebugeng.impl.DLL!ImplDllCreateInstance+0x6f39e VSDebugEng.dll!DkmDllEnsureInitialized+0x81915 VSDebugEng.dll!DkmDllEnsureInitialized+0x5278a VSDebugEng.dll!DkmDisplayRetailAssert+0x1c1e VSDebugEng.dll!DkmDisplayRetailAssert+0x2206 VSDebugEng.dll!ProcFFE7BBBBC1EC94B9CB3791B48190C3C2+0x255f1 VSDebugEng.dll!DkmDllEnsureInitialized+0x8f53b vsdebugeng.impl.DLL!DllGetClassObject+0x3417 vsdebugeng.impl.DLL!DllGetClassObject+0x351a vsdebugeng.impl.DLL!DllGetClassObject+0x1d89 vsdebugeng.impl.DLL+0x10c6 kernel32.dll!BaseThreadInitThunk+0x12 ntdll.dll!RtlInitializeExceptionChain+0x63 ntdll.dll!RtlInitializeExceptionChain+0x36

[FortranFan]

Is it possible for you to post here a simple reproducer example along with all your project and solution files?

I haven't noticed any issue with Fortran-only projects in VS2012.

[Samuel_D_]

Yes should be possible since I have now a case that is systematic. It's an allocation of a two dimensional derived type array. Let see if I can isolate the pb...

[Bernard]

@Samuel

I am not sure if the stack and its resolved symbols are correct(large offsets of called functions and strange name ProcFFE7BBBBC1EC94B9CB3791B48190C3C2).

I suppose that the hang could be caused by usp10.dll.AFAIK this DLL is used for Unicode script processing and was not resolved correctly by Process Explorer thus the offset usp10.dll+0x8580 is not mapped to any function.My "theory" is that code executed at this address usp10.dll+0x8580 hangs when trying to parse encoding of the opcode to which the corresponding intrinsic is translated.

[Samuel_D_]

Hello Iliapolak, Is there any way to get Process explorer resolve the symbols correctly ? We don't have the symbols for VSDebugEng.dll right ? That sounds like an interesting theory ! Do you mean that encoding of the opcode is in unicode ? Is there anything I can do to workaround the problem ?

[Bernard]

Samuel D. wrote:

Hello Iliapolak,

Is there any way to get Process explorer resolve the symbols correctly ? We don't have the symbols for VSDebugEng.dll right ?

That sounds like an interesting theory ! Do you mean that encoding of the opcode is in unicode ? Is there anything I can do to workaround the problem ?

Hi Samuel

In order to resolve symbols Process Explorer must first access windows public debug symbols.Those symbols can be freely downloaded from this link:

http://msdn.microsoft.com/en-us/windows/hardware/gg463028.aspx

You can also install windbg and specify symbol path by using this command .sympath SRV*f:\localsymbols*http://msdl.microsoft.com/download/symbols

http://support.microsoft.com/kb/311503

Bear in mind that only public symbols are freely available.In your case public symbols(pdb) of  usp10.dll are needed to resolve this address usp10.dll!+0x8580.I suppose that this address is responsible for the CPU hog.Anyway in order to gain more insight into this issue windbg should be used.I do not really know if the encoding is in Unicode I can only theorize by looking at the call stack.Regarding  VSDebugEng.dll  symbol resolution we can only be sure if the right symbols are used during the debugging in such a case windbg will download the correct symbols automatically.