Mature code rebuilds experiencing bizarre errors - anyone else?

[bharper]

I've been rebuilding various mature complex codes recently (mainly IFORT developed), some unchanged, some minor changes and I'm seeing some bizarre crashes around stack overflows and exceeding record lengths etc.  Also issues with some faily simple code. I have re-installed VS, Base and HPC twice and at least got to see debugger variables again. I'm using Windows 11 latest environment and half way down the rabbit hole at this point ...

Just wondering if anyone else out there is seeing any similarly strange issues that they cannot fix.

[andrew_4619]

Well I am not seeing these issues. I assume this is IFX? The stack overflow is probably temporaries being created that behaviour ifort / IFX is not identical. I think it is the optimisation reports that gives some info on that but the traceback should also give some clues. That is very fixable. I would check the byterecl setting as record length unit can be 1 byte or 4 byte depending.

[bharper]

Hi Andrew, thanks for that advice. Meanwhile I have found that some old code using ENTRY statements is responsible for one problem application. I recall that compilers rarely reject ENTRY code but it can still fail at runtime. In this case the same routine worked fine in one version but crashed the later one. Have rewritten the offending code as explicit calls and understand that ENTRY is now regarded as non-standard.

Meanwhile my VS debugger has lost its ability (yet again) to display variable contents. The recommended unset OPTION 'load debug symbols...'  is "set active but greyed out" as per below. Appreciate any advice on how to unset that (again).

[jimdempseyatthecove]

Is this a Release or Debug Build?

Console App or Windows App?

Main code Fortran or something else (C, C++, C#, Visual Basic, ...)?

In the project properties (of the project with the source with the symptoms) are Debug symbols set to be enabled?

In the Link properties of the startup project (or library) set to include Debug symbols?

Note, if the (non-visible content) variables are contained within a module, you will need to prefix the variable name with the module name:

The module name in the above screenshot is "mod_host".

Follow the module name with "::".

I too have encountered situations where some variables have issue with examination in the debugger. The trick I use to work with these is through the use of ASSOCIATE

...
associate(pFOO => FOO)
val = val + FOO ! look at pFOO
end associate
...

I normally place the debugging aid associate(s) at the beginning of the procedure and end associate at the end of the procedure.

...
integer :: i
associate( &
  pFee => Fee, &
  pFi => Fi, &
  pFo => Fo, &
  pFum => Fum)
 ! code follows
 ...
end associate
return
end subroutine zzzzz

The associates should not cause any additional processing overhead.

Jim

[bharper]

Hi Jim,  thanks for your detailed commentary and suggestions. I'll certainly try implementing "associate" to try and get around the flaky debugger issue, which by the number of Google searches on the topic over the years, seems to be endemic. After I reinstalled VS+Fort twice last week, the debugger was actually showing variables, but sometime later it broke once again. Hard to imagine how that works.

Answering your specific questions, this particular problem code is rather simple, console, all FORTRAN, MAIN code call to S/R, debug enabled mode. I'll just need to strip it down line-by-line and then arg-by-arg (old school). In comparison, the other code that was affected by ENTRY comprises thousands of lines of code and windows interfaces galore. At least the debugger pointed me at the problem interface, but that was really no better than the reported debug line number. The offending ENTRY code seemed fine by the way, but there you go. Probably not worth referring to the devs, likely another bug lurking nearby.

Cheers.

Bruce.

[jimdempseyatthecove]

It might be relatively easy to split your problematic ENTRY procedure into 3 or 4 components.

1) If you have SAVE variables, place them into a module (at the front of the same source file).

2) Split the source of the procedure immediately above the ENTRY,

     insert: CALL YouMakeUpAnameHere(repeat args..., plus ENTRY args if any); return

     Don't forget to insert USE TheModuleYouMade at the front of this procedure.

3) Following ENTRY line 

     insert: CALL YouMakeUpAnameHere(repeat main procedure args...., plus ENTRY args if any); return

     Don't forget to insert USE TheModuleYouMade at the front of this procedure.

4 insert: subroutine YouMakeUpAnameHere(repeat main procedure args...., plus ENTRY args if any)

              USE TheModuleYouMade at the front of this procedure.

              (declare dummy args)

              (copy common local vars declarations from original procedure)

               ... remaining code ...

          end subroutine YouMakeUpAnameHere

Something like that.

There may be something flaky with MS VS. A couple of weeks ago, Windows Update did an update overnight while I was (unintendedly) running a simulation program (which can take a few days to complete). Luckily this program makes checkpoints, so I didn't lose much. However, the update tweaked stuff in MS VS Community, which took me several minutes to correct. The update also changed my power plan. I do not understand why the MS developers don't understand that if the CPU has a process with one or more threads that are CPU bound, that the system is not ready for Hibernation. IOW don't just monitor mouse and/or keyboard activity.

Jim

[JohnNichols]

I do not understand why the MS developers don't understand that if the CPU has a process with one or more threads that are CPU bound, that the system is not ready for Hibernation. IOW don't just monitor mouse and/or keyboard activity.

Because the people who write the code are not heavy numerical code people.  Most are not, few people know the joy of seven days waiting for a FEM to run and you have a power glitch.  I am mean heaven.  

[bharper]

Thanks to all who took an interest in this post and made helpful suggestions.

Recapping:

The issue I had with a large complex code (windows) crashing was traced to a small utility character s/r code that used ENTRY statements. The code crashed as soon as the call was made. Although the code looked fine to me, the compiler did not object to it, and it has been in use for decades, I simply recoded it into separate s/r calls and avoided the crash.

The issue with a relatively short console-based code was that WRITEing a TRIMed(CHARACTER*512) variable to file would invoke an "exceeding record size" error" even though the variable could be PRINTed OK without error. The issue was traced to a utility CHARACTER*256 function that was used to populate the CHARACTER*512 variable via TRIM(). For whatever reason, this caused a spurious character (maybe nul) into the string, which when PRINTed simply forced a leading <CR>, but when written to file it forced the error/crash. Issue solved by making the utility function CHARACTER*(*), which it should have been (legacy etc). The file RECL was 1024.

Visual Studio debugging continues to behave erratically on my system - sometimes the variable contents are visible (rarely and ramdomly?) and most times they are not. Also, in single stepping (the only feature now left of use), upon entry to a s/r and passing the interface section, the first statement "pointed to" would not be the first exectauble statement in the code, but somewhere else lower in the routine. Stepping forward again would move the pointer back to the first exectuable.

INTEL: Any chance you can get MS to "fix" the FORTRAN variable visibility issue? Are there any alternative debuggers?

[andrew_4619]

Compile with interface checking and fix all mismatches. It makes for more reliable code.

[jimdempseyatthecove]

This looks like you have (had) a procedure interface problem. See if you are passing a CHARACTER*256 variable to a procedure that declares the dummy argument as a CHARACTER*512 variable. Any writes to this variable by the procedure would trash memory following the actual variable. Conversely, should you pass a CHARACTER*512 variable to a procedure that declares the dummy variable as a  CHARACTER*256 and which writes to this variable, then the last 256 characters of the actual argument would be untouched.

Jim Dempsey