Puzzling DEBUG occurrence

[WSinc]

This routine was (until I fixed it) was generating a breakpoint when it read a line from LGU 3.

It did tell me where the breakpoint was in the output file, but the debug arrow pointed to somewhere else in the program

that didn't even any I/O statements. In fact it pointed to the END of a routine that had nothing to do with this one at all.

also when it generates the breakpoint, it will not identify any symbols within this routine when I put the cursor on them.

Apparently the debugger does not generate the correct info regarding WHERE the breakpoint occurred, even though

the output file DOES have the correct information.

Any clues as to why this might occur? Apparently the interaction between the I/O library and the debugger is messed up.

If I need to upload the whole program to isolate this, I can do so.

[Steven_L_Intel1]

Possibly the executable you're debugging is not the one most recently built, but that seems unlikely. If you can continue to reproduce this, ZIP the entire project including the built EXE and attach that, with instructions for reproducing the issue.

[jimdempseyatthecove]

Is uscram compiled with or without optimizations?

Jim Dempsey

[WSinc]

I simplified this, so it just has the files needed.

That ZIP, is that a special application I need to get? Where?

Anyway, here are the files - - 

[WSinc]

Another file I forgot - - - 

Just hit "run" you dont need anything else.

I purposely put a glitch in the input file, to trigger a breakpoint.

[Steven_L_Intel1]

The program runs to completion without error for me.

[WSinc]

The problem seems to be triggered when I make mods to a routine, then say RUN.

If I compile it first, and then do a rebuild, I dont see it as often.

apparently you cant make changes without doing a recompile first.

It does compile it then, but then something gets messed up with the debugger.

[mecej4]

If you have a project in which the dependencies have been incorrectly specified (or inferred by applying rules), the chain of events that ensue when a button is pressed (RUN, for example) may be incorrect or incomplete. Sometimes, such problems can be detected by examining the command line in the VS panels.

[WSinc]

Can you try putting in a "glitch" in the input file "solns.txt" to trigger a breakpoint on the READ(3 statement?

I thought what I uploaded already had that.

And then do a minor mod to the USCRAM routine (like insert a blank somewhere) and run it without compiling it first?

I wanted to see what happens on your end when it tries to do a breakpoint. On my end, there is no debug arrow, and the symbols do not get loaded into that routine. But, the output pane DOES show what happened, and where.

I don't understand what mecej4 meant about "rules." If you make a MOD, isnt it by default supposed to examine each routine for recent mods and recompile it before doing the build? Apparently, if I recompile a USE module, all routines that include that get compiled afterward. But there is not a strict compile order for the others, right?

For example, if SUB1 calls SUB2, does it know to compile SUB1 first? It should if I made any changes to the interface between them.

It does recompile it, but something goes wrong in the BUILD process, causing the debug info to be omitted.

Like I said before, if you do the recompile yourself, THEN the build goes OK, and the debug stuff gets loaded.

BTW, where do I get this ZIP thing you referred to?

If you did a remote assist, I could show directly what the problem is - - - 

[Steven_L_Intel1]

ZIP is a very common data compression and archiving format that is supported across many platforms. Windows has some built-in support for it - if you select a folder or a set of files, right click on it, you can select "Send to > Compressed (zipped) folder" which will create a .zip file. A popular freeware tool that I can recommend is 7-zip (which supports many compression/archiving formats including ZIP. WinZip is probably the most popular commercial tool. When uploading multiple files, and files whose types are not directly supported for upload, collect them into a ZIP file and upload that. It saves space and bandwidth too.

Sometimes the build dependency generator gets out of sync and you end up needing to do manual compilation. One way to fix this is to remove and readd all the sources to the project.

I added an error to solns.dat (you uploaded .txt but the program asks for solns.dat so I just renamed it), and when the error occurred, the debug window showed me the correct line.

Let me ask you this - what is your setting for Tools > Options > Projects and Solutions > Build and Run > On run, when projects are out of date? My guess is you have this set to "Never build". If so, change it to either "Prompt to build" or "Always build" and then try your experiment again.

[WSinc]

OK, I zipped the entire project AND the input file here.

Most of the time I do not get debug symbols in the routine that generates the breakpoint.

I tried those build options, actually it was already set to "always build" so I changed it to 

"prompt before." It didn't make any difference.

[Steven_L_Intel1]

Bill,

I removed your ZIP as the source files contained inappropriate language. I understand that you may be frustrated, but if you want to continue to receive help here you need to maintain professionalism.

The general problem you have described, of the debug location not lining up, is usually caused by running an executable compiled with sources that were not the same as used for the build. You also need to realize that a VS project contains links to the source files and moving the files without the project system seeing the change is going to cause problems.

[WSinc]

I thought those ZIP files were for staff viewing only - are they viewed publicly?

Anyway, I tried to illustrate the problem better by showing that ALL the files were in one location.

Even when I rebuild the project in the same location as the source files.

Since I still experience the same issues, maybe some one else has some ideas about this ?

If it is caused by something in MY system, then only a "remote assist" would isolate it

and it would not be addressed by sending the files elsewhere.

[WSinc]

Actually, this might have been caused by something I pointed put before, namely

That it puts the project in a weird unaccessable location FAR removed from where the source files are.

Of course, making the INPUT files to be in the same location makes it even more awkward - - 

I can try forcing the output files to a better location. But still I am wondering why they had to make it so difficult.

[mecej4]

billsincl wrote:
it puts the project in a weird unaccessable location FAR removed.

That "it" could actually, if inadvertently, have been you, namely, billsincl! Let me explain how: when you launch Visual Studio and create a new project (or create a new Fortran project from existing files), you are given a menu where you specify, among other things, the location for the project files. The location may have been filled in based on what Visual Studio remembers from previous sessions, but you have the opportunity to change the location or accept the location offered. In either case, you should note the location (mentally, on paper or in a file) before proceeding. Similar comments apply for storing newly created program text files and data files. Until you become sufficiently experienced to know where VS puts various files, why not be a bit more methodical and specify file locations yourself, instead of accepting the VS-chosen locations? After you have more experience, you can probably ease up and accept the VS-chosen locations.

[Steven_L_Intel1]

Files you attach to a forum thread are visible to the public. Files you attach to a private message are visible to the recipient of the message and Intel Staff, though if someone can deduce the URL it could be retrieved. If you really need private communication, use Intel Premier Support. Nevertheless, such language as you used in the source would be inappropriate for any audience and is unlikely to get you the help you want.

I agree with mecej4 that the problems you're encountering are, it would seem, largely of your own doing.

[WSinc]

well, I would be happy to admit it and fix it if I could isolate my problem on my end  -  but:

1) the problem of disappearing DEBUG info appears to be a random occurrence, i.e. not making any changes sometimes allows

the symbols to appear or disappear, and

2) posting a breakpoint stop (the red dot) in the code forces the symbols to appear, so that is a temporary fix at least.

In other words, if I let the breakpoint occur from an error generation, then sometimes (randomly) the symbols and the arrow do not appear.

It goes to the assembly code, but then the line numbers and symbols don't appear.

I have an antivirus running, but after the initial build it does not scan my executable - so I dont see why that would be relevant.

If the problem were on my end, would not I always get the same occurrence? and finally -

3) why would I get this problem (randomly) if I have the source code in the usual default locations?

Unfortunately, since your system is different than mine, you are not likely to reproduce the same results if I send you the project. This is where a remote assist would be helpful. I would even be willing to pay for it, if it helps isolate any "user hostileness" issues.

Perhaps an upgrade to a later VS would cure some of the user hostile issues? Maybe they were addressed later on?

[jimdempseyatthecove]

How about this as a better work around:

When debugging, place a breakpoint at the first executable statement in PROGRAM. Start with debugging and press continue.

This way, you can load the symbols at the start of the program and (hopefully) have them available when you reach the unknown error location (e.g. X/ 0.0).

Note, if the error occurs in a library function this may not have symbols. When this occurs, the Call Stack can be examined to locate the call that began in one of your Fortran source files. If you double click on this reference in your Call Stack the debugger symbol scope changes to that level. You can then examine the calling arguments of the call immediately preceding the return location.

Jim Dempsey

[WSinc]

Very good suggestion -

It seems to be selective as to which source modules have the symbols loaded.

So I have to put the "red dot" somewhere in the routine that has the relevant breakpoint.

i.e. I have to run it twice, the first time when I know where the breakpoint occurs.

The main problem is trying to track down the values of the variables in that same routine that might lead to be problem.

Where do the debugger symbol locations actually get stored?

[jimdempseyatthecove]

I believe these are xxx.pdb files (Program Debug Database). After a build, you could file search for *.pdb limited to today.

These files are generally stored in the .obj folder, which is normally the same folder as the .exe file. If these folders are different .OR. if you copy the .exe to somewhere else then from VS click on

Debug | Options And Settings | Debugging | General | Symbols

Then add the path to where the .pdb files were directed to be placed.

(The above is for VS 2010, other versions may differ slightly)

Jim Dempsey