topic You would have to locate the in Intel® Fortran Compiler

Debugger not fully working

dondilworth — Thu, 13 Sep 2012 18:32:16 GMT

If I make an error in my Fortran code, it triggers an error message, typically about an internal write format or something like that. I would like to know exactly which line of which routine is the culprit. But the call stack only points to internal Microsoft routines, never to my own code.

Also, If I want to set a breakpoint to watch when a Fortran variable changes, I cannot do it. In VS10, I can click the New Breakpoint item and then New Data Breakpoint. Then I am supposed to select the language, either Fortran or C++. Problem is that I don't even get the first choice. It's C++ or nothing.

So I suspect I have set up my project incorrectly. (It was converted from VS6.) Can anyone tell me which settings I need to look at and how they should be set? Otherwise my program works, so most settings seem to be okay.

The language choice in

Steven_L_Intel1 — Thu, 13 Sep 2012 18:53:19 GMT

The language choice in setting the breakpoint has never offered Fortran - just choose C++. When the brakpoint occurs, the current stack frame is likely in a library call but you should be able to use the Call Stack pulldown to set the context to your code that started the operation. This is not new.

The call stack (when an error

dondilworth — Fri, 14 Sep 2012 15:28:38 GMT

The call stack (when an error occurs) does not even list any of my code. Only system stuff. That's the problem. Is there a setting I should change? Or are you not answering that question yet?

If the call stack doesn't

Steven_L_Intel1 — Sun, 16 Sep 2012 00:12:52 GMT

If the call stack doesn't show your code, then either the stack has become corrupted or the error is happening after your program exits. Can you attach an example program that demonstrates this problem? There is no special setting you should need.

My program is running when

dondilworth — Mon, 24 Sep 2012 20:30:54 GMT

My program is running when the error occurs, and I can set breakpoints and they work. So it is still running. I don't know about the stack. If that got corrupted, how do I fix it?

You would have to locate the

Steven_L_Intel1 — Wed, 26 Sep 2012 14:18:47 GMT

You would have to locate the bit of code that corrupted the stack and fix it. I was just theorizing - without an example it's hard to say more. This sort of problem is often difficult to diagnose.

Steve:

dondilworth — Wed, 26 Sep 2012 14:46:11 GMT

Steve: While I appreciate your taking the time to respond, please be aware that I'm only a dumb programmer. I don't have a hint of a clue how to diagnose a problem with the stack. Can you provide more explicit instructions, or point me to a document that explains what has to be done?

No, I can't give you

Steven_L_Intel1 — Wed, 26 Sep 2012 15:00:23 GMT

No, I can't give you instructions - the steps I tale when I do it are highly dependent on the particular application and mode of failure. It's also time-consuming. If you would like me to look at it, attach a ZIP of the project and tell me how to reproduce the error.

Presumably you have compiled

Les_Neilson — Wed, 26 Sep 2012 15:14:10 GMT

Presumably you have compiled in debug mode with all of the compile/runtime checks enabled? Do you use "implicit none" in your code? Stack corruption can be caused by a few things such as going out of bounds on an array or passing wrong arguments to a subroutine uninitialised variables may also cause problems later on. Les

Les:

dondilworth — Wed, 26 Sep 2012 15:29:58 GMT

Les: To be sure I didn't omit any important checks, please direct me to the tab and items that should be turned on. There are so many of them, it is possible I missed something. I never use "implicit none". If I go out of bounds on an array or pass the wrong argument, that is exactly the kind of error I want the debugger to flag. If that error screws up the debugger, then it is less useful than I had hoped. Isn't a debugger supposed to help one find programming errors? It is not easy to provide this project for an example. The files together are over a GB, and the registry has to be initialized properly. Few people are willing to invest so much effort. I wish I could. I also wish I wrote very small programs. But this is late in my career. I appreciate all advice.

Well the use of implicit none

Les_Neilson — Wed, 26 Sep 2012 15:56:43 GMT

Well the use of implicit none would really help in identifying any possible typos. It may be a slog to edit all of the code but is probably worth it in the long run. The compiler can't necessarily tell you whether x(k) has k out-of-bounds. The debugger helps if you have the run time checks on; then when the program dies it is usually able to tell you why it died. Compile options : In Visual Studio under Project->Fortran ->Debugging->Debug Information Format Full ->Diagnostics I have "Warn for undeclared symbols" set (plus others) ->Data "Initialize stack variables to an unusual value" set to Yes ->Run-time->Generate Traceback Information set Yes and Runtime Error Tracking set to "All" ->External Procedures what do you have set for the Calling Convention? Must go now Les

These are all very helpful.

dondilworth — Thu, 27 Sep 2012 16:27:04 GMT

These are all very helpful. I have all of your settings except "Warn for undeclared symbols". I use IMPLICIT DOUBLE PRECISION (A-H,O-Z) and CVF (/iface:cvf) My usual bugs are index out of bounds, which the debugger nicely finds for me, and output format errors, which it does not. I'll do some simple tests and post the messages I get.

Here is a glaring example: I

dondilworth — Sun, 30 Sep 2012 16:01:42 GMT

Here is a glaring example: I code the following error, where double-precision X is written an integer format:: X = 0.0 WRITE(KOUT,6001) X 6001 FORMAT(I5) When I run this, I get an error dialog, which is attached. It says all of the calling routines are unknown. The call stack says: > libifcoremd.dll!0017d045() [Frames below may be incorrect and/or missing, no symbols loaded for libifcoremd.dll] SYNOPSYS200v14.exe!CWnd::WindowProc(unsigned int message, unsigned int wParam, long lParam) Line 2088 + 0x1c bytes C++ SYNOPSYS200v14.exe!AfxCallWndProc(CWnd * pWnd, HWND__ * hWnd, unsigned int nMsg, unsigned int wParam, long lParam) Line 257 + 0x1c bytes C++ SYNOPSYS200v14.exe!AfxWndProc(HWND__ * hWnd, unsigned int nMsg, unsigned int wParam, long lParam) Line 420 C++ user32.dll!76ae62fa() user32.dll!76ae6d91() user32.dll!76af8098() user32.dll!76af0c91() user32.dll!76afa0c7() SYNOPSYS200v14.exe!AfxLockGlobals(int nLockType) Line 94 C++ Obviously, this is no help at all for finding where in my code I have made an error. Is this normal?

Well, you found your error -

Steven_L_Intel1 — Mon, 01 Oct 2012 01:13:06 GMT

Well, you found your error - it's in the code you posted. It's not allowed to write a REAL value using an I format. We do have a compiler option to allow this to go through, but the results may not be what you expect. Which compiler version did you use and what were the build options? Perhaps this was not a debug build or you didn't build with traceback enabled? This isn't a debugger error, however.

I'm afraid you missed the

dondilworth — Mon, 01 Oct 2012 13:40:24 GMT

I'm afraid you missed the whole point of my post. I did not "find" my error; I created that trivial error in order to test whether the debugger could find it and tell me where it is. It did not. That was the point. My code has lots of internal writes all over the place, and if one of them triggers this error, at present I have to find and examine every one of them. That's supposed to be the debuggers job. It failed. That's my complaint. Perhaps it's not a debugger error, but it surely is a debugger shortcoming. I have your Fortran XE 2011, updated last month. Are there any build options that will make the debugger do what I need? This example was indeed a debug build. I migrated from CVF, and this kind of error was nicely located by their debugger. Maybe I'm spoiled, but it seems like a reasonable expectation. What can I do?

I see. Well, when I tried a

Steven_L_Intel1 — Mon, 01 Oct 2012 16:07:48 GMT

I see. Well, when I tried a test case the debugger did break when the program hit the error and the traceback listed the source file and line number. I don't know what options got carried over from your CVF project. I also note that this particular error is NOT enabled by default, so you would have had to ask for it. Please attach the buildlog.htm from the Debug folder and I'll see if I can spot the problem.

Great! This is progress --

dondilworth — Mon, 01 Oct 2012 17:24:46 GMT

Great! This is progress -- but the file cannot be attached. The selected file BuildLog.htm cannot be uploaded. Only files with the following extensions are allowed: txt, ppt, pptx, doc, docx, pdf, zip, tgz, tar, jpg, jpeg, cap, rtp. So here the text is copied below. Good luck. Build Log Build started: Project: SYNOPSYS200_lib_, Configuration: Debug|Win32 Output Compiling with Intel(R) Visual Fortran Compiler XE 12.1.5.344 [IA-32]... ifort /nologo /debug:full /Od /I"Debug/" /reentrancy:none /extend_source:132 /Qopenmp /Qopenmp-report1 /warn:unused /warn:truncated_source /Qauto /align:rec4byte /align:commons /assume:byterecl /Qtrapuv /Qzero /fpconstant /iface:cvf /module:"Debug/" /object:"Debug/" /Fd"Debug\vc100.pdb" /traceback /check:all /libs:dll /threads /winapp /c /Qvc10 /Qlocation,link,"c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\\bin" "C:\SYNOPSYSV14\User.for" C:\SYNOPSYSV14\User.for(39): remark #8291: Recommended relationship between field width 'W' and the number of fractional digits 'D' in this edit descriptor is 'W>=D+7'. 5001 FORMAT(4(G22.16,',')) ------------------^ C:\SYNOPSYSV14\User.for(89): remark #8291: Recommended relationship between field width 'W' and the number of fractional digits 'D' in this edit descriptor is 'W>=D+7'. 6001 FORMAT(6E13.7) -----------------^ C:\SYNOPSYSV14\User.for(386): remark #8290: Recommended relationship between field width 'W' and the number of fractional digits 'D' in this edit descriptor is 'W>=D+3'. 5001 FORMAT(F10.6,1X,F10.8) -------------------------^ C:\SYNOPSYSV14\User.for(475): remark #7712: This variable has not been used. [ZS] SUBROUTINE UGRINN(XARG,YARG,ZS,RN,DNDX,DNDY,DNDZ,DT,M,J,ICOL,JGN) ----------------------------------^ C:\SYNOPSYSV14\User.for(475): remark #7712: This variable has not been used. [DT] SUBROUTINE UGRINN(XARG,YARG,ZS,RN,DNDX,DNDY,DNDZ,DT,M,J,ICOL,JGN) -------------------------------------------------------^ C:\SYNOPSYSV14\User.for(475): remark #7712: This variable has not been used. SUBROUTINE UGRINN(XARG,YARG,ZS,RN,DNDX,DNDY,DNDZ,DT,M,J,ICOL,JGN) ----------------------------------------------------------^ C:\SYNOPSYSV14\User.for(475): remark #7712: This variable has not been used. SUBROUTINE UGRINN(XARG,YARG,ZS,RN,DNDX,DNDY,DNDZ,DT,M,J,ICOL,JGN) ------------------------------------------------------------^ C:\SYNOPSYSV14\User.for(475): remark #7712: This variable has not been used. [ICOL] SUBROUTINE UGRINN(XARG,YARG,ZS,RN,DNDX,DNDY,DNDZ,DT,M,J,ICOL,JGN) --------------------------------------------------------------^ C:\SYNOPSYSV14\User.for(495): remark #7712: This variable has not been used. [ZS] SUBROUTINE UPGNN(ZS,YA,RN,DNDY,DNDZ,DT,M,J,JGN) -----------------------^ C:\SYNOPSYSV14\User.for(495): remark #7712: This variable has not been used. [DT] SUBROUTINE UPGNN(ZS,YA,RN,DNDY,DNDZ,DT,M,J,JGN) ------------------------------------------^ C:\SYNOPSYSV14\User.for(495): remark #7712: This variable has not been used. SUBROUTINE UPGNN(ZS,YA,RN,DNDY,DNDZ,DT,M,J,JGN) ---------------------------------------------^ C:\SYNOPSYSV14\User.for(495): remark #7712: This variable has not been used. SUBROUTINE UPGNN(ZS,YA,RN,DNDY,DNDZ,DT,M,J,JGN) -----------------------------------------------^ C:\SYNOPSYSV14\User.for(512): remark #7712: This variable has not been used. [ZS] SUBROUTINE UPGNN3(ZS,YA,RN,DNDY,DNDZ,DT,M,J,CN1,CN2,JGN,RNC,RNF) ------------------------^ C:\SYNOPSYSV14\User.for(512): remark #7712: This variable has not been used. [RN] SUBROUTINE UPGNN3(ZS,YA,RN,DNDY,DNDZ,DT,M,J,CN1,CN2,JGN,RNC,RNF) ------------------------------^ C:\SYNOPSYSV14\User.for(512): remark #7712: This variable has not been used. [DT] SUBROUTINE UPGNN3(ZS,YA,RN,DNDY,DNDZ,DT,M,J,CN1,CN2,JGN,RNC,RNF) -------------------------------------------^ C:\SYNOPSYSV14\User.for(512): remark #7712: This variable has not been used. SUBROUTINE UPGNN3(ZS,YA,RN,DNDY,DNDZ,DT,M,J,CN1,CN2,JGN,RNC,RNF) ----------------------------------------------^ C:\SYNOPSYSV14\User.for(927): remark #7712: This variable has not been used. [JFLAG] SUBROUTINE USRCV(CURV,JFLAG,J) ----------------------------^ C:\SYNOPSYSV14\User.for(1026): remark #7712: This variable has not been used. SUBROUTINE TEST2(W,Z) ! UNUSED AT PRESENT -----------------------^ C:\SYNOPSYSV14\User.for(1026): remark #7712: This variable has not been used. SUBROUTINE TEST2(W,Z) ! UNUSED AT PRESENT -------------------------^ C:\SYNOPSYSV14\User.for(1107): warning #6371: A jump into a block from outside the block may have occurred. [25] 30 READ (69,5001,END=25,ERR=997) LINEIN ! READ LOOP STARTS --------------------------^ C:\SYNOPSYSV14\User.for(1044): remark #8291: Recommended relationship between field width 'W' and the number of fractional digits 'D' in this edit descriptor is 'W>=D+7'. 5003 FORMAT(6E13.7) ---------------^ C:\SYNOPSYSV14\User.for(1101): remark #8290: Recommended relationship between field width 'W' and the number of fractional digits 'D' in this edit descriptor is 'W>=D+3'. WRITE(LINEOUT(35:38),'(F4.2)') C ! IS SP.GV. ----------------------------------------^ Creating library... Lib /OUT:"Debug/SYNOPSYS200_lib_.lib" /NOLOGO "Debug/S09.obj" "Debug/MC.obj" "Debug/Ai2.obj" "Debug/Worksheet.obj" "Debug/S03.obj" "Debug/Film.obj" "Debug/Dovl09.obj" "Debug/Dovl23.obj" "Debug/Dovl03.obj" "Debug/S08.obj" "Debug/Lp.obj" "Debug/Ai1.obj" "Debug/S02.obj" "Debug/Expert.obj" "Debug/Dovl08.obj" "Debug/Dovl16.obj" "Debug/Dovl02.obj" "Debug/S07.obj" "Debug/Ai.obj" "Debug/W95pad.obj" "Debug/S01.obj" "Debug/Dovl54.obj" "Debug/Dovl07.obj" "Debug/Nonseq.obj" "Debug/dovl14.obj" "Debug/Automf.obj" "Debug/S06.obj" "Debug/Lck.obj" "Debug/User.obj" "Debug/Dovl44.obj" "Debug/Dovl06.obj" "Debug/S11.obj" "Debug/Dovl13.obj" "Debug/S05.obj" "Debug/Global.obj" "Debug/Tosp.obj" "Debug/Realpupil.obj" "Debug/Dovl34.obj" "Debug/Dovl05.obj" "Debug/S10.obj" "Debug/MOMF.obj" "Debug/Dovl12.obj" "Debug/Ai3.obj" "Debug/Wview.obj" "Debug/GlassTable.obj" "Debug/Dovl10.obj" "Debug/S12.obj" "Debug/Polar.obj" "Debug/Dovl24.obj" "Debug/Win95.obj" "Debug/S00.obj" "Debug/MultiThread.obj" "Debug/S04.obj" "Debug/Dovl04.obj" xilib: executing 'lib' SYNOPSYS200_lib_ - 0 error(s), 1 warning(s)

I don't see anything unusual

Steven_L_Intel1 — Mon, 01 Oct 2012 18:06:54 GMT

I don't see anything unusual in that log. As an experiment, try creating a new project and adding your source files to it. Make only the minimal project setting changes required (for example, you probably do want /Qopenmp but probably don't need /iface:CVF. Turn on /check:all too. See what happens. I have tried a bunch of different combinations with my test project and I always get the traceback and breakpoint.

What you suggest is a huge

dondilworth — Mon, 01 Oct 2012 20:48:42 GMT

What you suggest is a huge undertaking. This is an immense program, half Fortran and half C++, with 50 years of development behind it. I converted from CVF per the Visual Studio 2010 menu item "Extract Compaq Visual Fortran ...", because nothing made any sense otherwise. So one way or another I am stuck with the present setup. If I compile with iface:CVF changed to cref or stdref, I get zillions of compile errors about character strings passed as REFERENCE. I don't want to make sweeping changes to my code since that will probably create zillions of bugs all over the place. There must be a simple setting somewhere that will make the debugger work. Has anyone else had this problem?

Clearly in your case turning

Steven_L_Intel1 — Mon, 01 Oct 2012 20:59:19 GMT

Clearly in your case turning off /iface:CVF is not appropriate. I was just suggesting that because most projects converted from CVF don't need it, not because I thought it had any bearing on your situation. I have not seen other reports of a problem like this. Perhaps you can try creating a small test project just to see that it normally works. Please attach a ZIP with the .vfproj and .vcproj files of all the projects in the solution. Maybe I'll see something there. The log you posted is not from the executable project, so perhaps there's something wrong on the C side.