Debugger failure

[Horsewood__Jerry]

I am re-compiling a legacy Fortran 77 program using the Intel XE 2018 compiler with VS 2017 Community Edition. This is my first attempt at developing a project of F77 code, although I have other projects in F90 code. My problem is that I am unable to run the code in the IVF debugger. When I start the program without debugging, it runs to completion, although with data errors whose cause remains to be determined. When I start with debugging after setting a breakpoint at the first executable line of code, the program appears to start, the console window appears and a yellow arrow appears in the red dot at the breakpoint. But after a few seconds, the empty console window closes and the VS window closes momentarily before reappearing with the program terminated. No errors are reported. Does anyone have suggestions for resolving this issue?

[jimdempseyatthecove]

Compile the program with all the compile time diagnostics, in particular argument checking. Correct any/all issues.

If the problem remains, you may have an issue with your AntiVirus program terminating the program. To correct for this, add the Debug (or x64\Debug) folder to the exclusion folders.

Jim Dempsey

[Horsewood__Jerry]

I have compiled with all the compile time diagnostics and corrected all problems and no error messages are produced. Additionally, I have attempted to run while debugging with the anti-virus software disabled. In addition, I re-developed the project from scratch on the outside chance I had corrupted something the first time. After all this, the results remain unchanged.

[mecej4]

The behavior that you described suggests that the EXE that is being run under control of the debugger is missing debug support in some parts of it.

Here is one thing to try: add a PAUSE statement just before the place where the program is terminating. This place may be the last statement of the main program, or some other statement whose execution causes an error and termination.

Instead of PAUSE, you can also add pairs of WRITE/READ statement pairs at selected locations in the source code.

If you can share the VS build log, that may be useful.

[jimdempseyatthecove]

One additional thing to do is on the off chance that you are experiencing an MS VS Debugger issue (with Intel Fortran) where the list of break points gets goofed-up. What you see as break points is not what the Debugger sees. To clear this up, from the VS IDE in edit mode (IOW not in Debug mode), click on

Debug | Windows | Breakpoints

In the Breakpoints, click on the Red X to delete all breakpoints
**** DO NOT DELETE THEM INDIVIDUALLY *** (not the same thing)

Red X, my assumption, appears to delete the container for all the breakpoints, whereas deleting them individually keeps the container around. This old bug in MS VS require the deletion of the container (Red X) to correct the problem.

Jim Dempsey

[Horsewood__Jerry]

The suggestion to use Pause was very productive and exposed a compiler behavior I don't understand. The offending code was isolated to the handling of the command line, which was the first action in the main program. The code appeared as follows:

        call Get_Command(CmdLine)
	CmdLine = AdjustL(CmdLine)
	J = Index(CmdLine, ".exe") + 6
	CmdLine(1:) = CmdLine(J:Len(CmdLine))

I defined the Debugging Command Arguments attribute to be the desired command line passed to the program and ran the program. Because of errors in the program, the compilation failed. After correcting the code at the indicated error, I ran the debugger again and found that the program issued a message saying the information supplied in the command line was not found. A check of the Command Arguments attribute showed that it was blank. Rather than reset the attribute each time, I added an additional line of code following the last line above. This line reads as follows:

      CmdLine(1:) = "Runcase Runcase"

Placing a Pause statement before this line causes the Pause to be executed. Placing the Pause after the added line resulted in the failure that prompted this topic. Additionally, if the original four lines are commented, the problem goes away. This would seem to be a compiler bug. I also think that the failure of the Command Arguments attribute to be retained through multiple debugging sessions should also be considered a bug. Thanks to all for their suggestions in resolving this problem.

[Steve_Lionel]

I would like to see a reproducible test case before passing judgement on a possible compiler bug. I strongly suspect that something else is going on here that we're not seeing. Such a test case would also need to include the project file.

Any reason you're not using GET_COMMAND_ARGUMENT?

[Horsewood__Jerry]

I created a new project to test the situation in a simpler environment. Here is the code:

      Program CmdLineTest
          Character*127 CmdLine
          Integer J
          call Get_Command(CmdLine)
          CmdLine = AdjustL(CmdLine)
          J = Index(CmdLine, ".exe") + 6
          CmdLine(1:) = CmdLine(J:Len(CmdLine))
          CmdLine(1:) = "Arg3 Arg4"
          write(*, '(3A)') '"', CmdLine(1:Len_Trim(CmdLine)), '"'
          Pause
          stop
      end

Running this code as is results in the correct console output of "Arg3 Arg4". If one comments the line immediately preceding the write statement, the correct output "Arg1 Arg2" is written if one redefines the Debugging Command Arguments to "Arg1 Arg2" before each run. However, if one places a breakpoint on any of the lines of code, the behavior I first described (i.e., the program starts by displaying the blank console window, is in a wait state for a few seconds, then closes down and restarts in the project window). When the project window is restored, the breakpoint indicator is missing but selecting Debug/Window/Breakpoints reveals the container remains and running again with the absent indicator but without eliminating the container causes the same error to occur again. So, the problem seems to be with the setting of breakpoints rather than the code itself. Possibly I have a wrong debug setting in the project setup. I've attached the project folder compressed to a rar file, so you may be able to tell from that.

[Steve_Lionel]

I took your RAR file - the project as you supply it has no command arguments defined in the Debugging property page. If I run the EXE you provide, it executes correctly. As provided, it stops at the breakpoint and stays there until I proceed, but displays no arguments since there aren't any. If I add arguments, then it does display them. I get the same behavior if I rebuild the executable.

[mecej4]

There may be errors caused by the way you parse the command line to obtain the arguments, and the way in which the command line is written. When I run within the debugger, the path of the EXE may contain blanks, and VS may enclose the entire path within double quotes, so the variable CmdLine has this value: "S:\lang\HorseWood\CmdLineTest\CmdLineTest\x64\Debug\CmdLineTest.exe" Arg1 Arg2 .

On the other hand, if I run the program from a command window with the command cmdlinetest argx argy, there is no substring ".exe" present, so J = 6, the printed value of CmdLine is netest  argx argy and your parsing has failed to deliver the proper arguments.

Why not use the intrinsic GET_COMMAND_ARGUMENT, as Steve suggested?

[Horsewood__Jerry]

Steve, I agree it works fine as written. The problem is when you set a breakpoint at any line, then it breaks. The issue now is that I cannot set breakpoints in the code because it causes the debug run to crash. Is this not an IVF issue? mecej4, you are correct. The actual program that this represents is invoked from an UI that always includes the '.exe' in the command line that launches the program, so it always works in that environment. Nevertheless, the call to Get_Command_Argument is the better option because then I can eliminate the local code to parse the arguments.

[Steve_Lionel]

It works fine for me with the breakpoint.

[mecej4]

I do not see any abnormal behavior, either. One more suggestion: add the following statement after line-6:

if (J == 6)stop 'Command line does not contain ".exe"'

[Horsewood__Jerry]

So this must mean that either: (1) something is wrong with the project setup, or (2) the VS 2017 installation is corrupted. I have gone over the project properties and see nothing wrong there and did a repair of the VS 2017. After that I ran the program with a breakpoint set at line 7. The program terminated as before, but issued an error message indicating an unknown software error occurred in devenv.exe, which is not my code and must be a part of VS. A screen shot of the message is attached. After clicking OK in the message box, the program terminated and did not restart. Subsequent attempts to repeat the behavior resulted in the termination of the program but without emitting the error message. I noticed that an update was available for VS 2017 and applied it. During the update, I noted that devenv.exe was included. I then reran the program, but no joy. My next step is to uninstall and re-install VS 2017 and IVF.

[Steve_Lionel]

devenv,exe is the Visual Studio IDE. As an experiment, temporarily disable your antivirus software - I have seen these sometimes interfere with software development. If that changes the behavior, you may be able to add an exception for your development folders.

That particular error is "The parameter is incorrect", meaning that there was a call to a Windows API routine that passed a bad argument. It's certainly possible that your VS install is corrupted, but I would lean more towards some other software on your system interfering. Do try the reinstall and see what happens.

[Horsewood__Jerry]

I disabled the virus protection and reran the case with the same result. The devenv error was again emitted with an option to debug. That produced a disassembly of the code with a pointer to an instruction that apparently led to the error. I've attached a screen shot of that portion of the disassembly in case that gives you any ideas.

[Steve_Lionel]

That's not helpful. Try a reinstall.

[Horsewood__Jerry]

I re-installed both VS 2017 and IVF and the breakpoints are now working. Thanks to all for their help and suggestions.