Debugger not fully working

[dondilworth]

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

[Steven_L_Intel1 · Accepted solution]

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.

[dondilworth]

This is super! I turned off incremental linking, and now the debugger tells me where the screwup is! Thank you. But now I cannot change something in the C++ code and continue debugging, which was a great time saver before. Why the connection? Do I have to give up one to get the other? You are correct about configuration problems. I had an awful time getting the system to work after migration. I have no routine called main(). The program starts at CSYNOPSYSApp::InitInstance(). Just getting it to start at the right place took days. Then I had to get the Sentinel key drivers to work, and I spent days on the phone with their TS guy, who managed to apply the band-aids. Even he was baffled for quite a while. Now, it actually works. Whew. Everything I tried myself gave me errors about something not being defined, or being defined more than once. I wasted an awful lot of time on this. If there is a way to organize my setup rationally, I would like to know about it. Can you provide explicit instructions? I'm no expert when it comes to setting up a new project. "If it ain't broke, don't fix it...."

[Steven_L_Intel1]

Yes, sorry, you have to give up incremental linking in order to get traceback, as the method we use for storing traceback info in the EXE is incompatible with incremental linking. I was not aware debugging was involved, and I am pretty sure I have debugged mixed-language applications where the C main had incremental linking. I'll have to play with that some more. The basic rule here is that you can't mix C library types, where those libraries are provided as static/DLL and debug/nondebug. Everything needs to be built against the same set of libraries or else you can get link errors. This can be a pain when you are using external libraries that were not built with /Zl (so that the library directives were left out of the objects.) You can sometimes get around this by setting the linker option to disable all library directives and then name the set of runtime libraries you want explicitly.