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.
DD
1 解決方案
Ok - I can see that you need to turn off Incremental Linking in the C project - this is what is disabling traceback.
You should also remove the VC98 folders from your system INCLUDE environment variables, not that this matters for the problem at hand. I also see you have various libraries listed as to be ignored during linking - this is usually a sign that you've got a configuration problem elsewhere and used this as a "Band-Aid" to cover up for it. Make sure that the C++ and Fortran projects, and the SYNOPSYS library you are linking against, are all built with the same setting for the run-time libraries being used. This mismatch can cause many problems.
連結已複製
23 回應
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 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 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.
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:
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 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 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:
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 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. 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 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 - 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 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 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 -- 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 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 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 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.
