Problem with breakpoints in PROGRAM in 64-bit debugger

[jirina]

I am using Parallel Studio XE 2016 Update 1 in Visual Studio 2010 Professional SP1 on Windows 10 Professional 64-bit.

If I place a breakpoint in the block between PROGRAM and END [PROGRAM] (I have only the specification and executable part, no CONTAINS) and run the 64-bit debugger, one of two scenarios happens:

1. Visual Studio crashes.
2. If I disable the breakpoint, let the console application hit another breakpoint in a subroutine, and re-enable the breakpoint, the debugger stops running and it opens a tab "No Source Available (No symbols are loaded for any call stack frame. The source code cannot be displayed.)". The call stack window is empty and it is possible to continue the run by pressing F5. I remember this behavior from earlier versions of Parallel Studio XE and I always switched to the 32-bit debugger that has never had this problem.

Re-installing Parallel Studio did not help. Is there anything I can try to be able to stop the 64-bit debugger using breakpoints in the main program?

[mecej4]

Is the problem specific to (i) a specific software combination (OS, Compiler, Libraries), (ii) a choice of compiler options or (iii) to a specific project? You seem to think (i) is the culprit.

I have a slightly different set-up (W10 X64 home, IFort 16.0 U1, VS 2013 Pro), and I tried the source files in #1 of https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/606074 as an example. The project is a mix F90 and F77, and does a rather mundane numerical calculation. I could not reproduce the problem that you described, using only the /Zi option. I was able to place breakpoints at a number of places and when they were reached everything looked normal.

[jimdempseyatthecove]

>>I have only the specification and executable part, no CONTAINS
seems to contradict
>> let the console application hit another breakpoint in a subroutine

Is this a Release build or Debug build?

With an early version of MS Visual Studio I once had the same problem. This was where a break point appeared to be set where I had not specifically set one. In this odd case the breakpoint was set in the middle of an instruction byte sequence (IOW not at first byte of sequence). After a lot of experimentation to try to rid the VS IDE from this break point, I found that if you go into the Breakpoint menu and select "Delete all breakpoints" that this worked. Note, deleting each set breakpoint individually did not work (as the mysterious one set was not listed).

Jim Dempsey

[jirina]

It is a debug build with following options for the compiler: /nologo /debug:full /MP /Od /fixed /extend_source:132 /Qopenmp /fpscomp:general /Qdiag-disable:8290,8291 /debug-parameters:all /warn:declarations /warn:truncated_source /warn:noalignments /warn:interfaces /assume:byterecl /module:"x64\Debug\\" /object:"x64\Debug\\" /Fd"x64\Debug\vc100.pdb" /traceback /check:pointer /check:bounds /check:uninit /check:format /check:arg_temp_created /check:stack /libs:dll /threads /dbglibs /c

Options for the linker are: /OUT:"x64\Debug\MyApp.exe" /INCREMENTAL:NO /NOLOGO /DELAYLOAD:"MyAppDLLx64.dll" /MANIFEST /MANIFESTFILE:"x64\Debug\MyApp.exe.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG /PDB:"D:\Source_Fortran\Test\x64\Debug\MyApp.pdb" /SUBSYSTEM:CONSOLE /STACK:100000000 /IMPLIB:"D:\Source_Fortran\Test\x64\Debug\MyApp.lib" delayimp.lib .\DLL\x64\MyAppDLLx64.lib

I hope there is no contradiction in my statement that I have subroutines that are called from the main program without being in CONTAINS. Could it be that the code was originally written in F77 and the compiler knows about it?

I wrote a very simple console application in F90 and breakpoints in the main program work well there. At the same time, I tested that calling a subroutine located in another .f90 file works well with this in BreakpointTest.f90:

program BreakpointTest
    implicit none
    integer i

    print *, 'Breakpoint Test begins.'
    
    call foo ( )
    
    do i=0,9
      write(*,'(a,i1)') 'i=', i
    enddo
    
    print *, 'Breakpoint Test finished.'

    end program BreakpointTest

and this in Subroutines.f90:

subroutine foo ( )
  print *, ' Subroutine foo() called. '
  return
end

Finally, I tried placing the breakpoint in my application to lines that are not executed paralelly, that contain a simple command (e.g. writing to console) or that call a subroutine; none of them works.

[mecej4]

You can download my source files from the link that I provided and build the application using the same options that you listed in #4. I did so (except for removing the options pertaining to DLLs, which my project does not use, and /fixed for the .f90 files), and the EXE behaved normally in VS 2013. You can test if it does so in VS 2010 in a few minutes.

Could it be that the code was originally written in F77 and the compiler knows about it?

I hope not. One of the attributes that a compiler should have is relentless forgetfulness. Well, there can be .OBJ and .MOD files that are detritus from previous compilations, and a compiler may get confused if it uses stale module files. Such a situation is easily avoided by building from scratch or doing a "clean and rebuild".

[jirina]

I downloaded your source files, used all compiler and linker options that I am using for my application (except those that are not applicable) and breakpoints in the main program work well. So, it is probably something in my application causing the problem. Thank you for your kind help so far.