Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
New Contributor I

Erroneous DEBUG behavior

Something goes wrong with the way the compiler sets up the debug info in particular routines.

I am using the most recent FORTRAN, so the problem might be in VS.

the breakpoint causes the green arrow to point to a routine that has nothing to do with where it occurs.

 

So I cannot look at the variables in the routine itself, I have to go back and insert print statements, or set breakpoints where it occurs,

which BTW - - does get properly reported in the output window.

 

I cannot use the call stack either, since the arrow is completely in the wrong place.

 

 

Not all routines behave this way, so it has to do with HOW COMPLEX the routine is, i.e how many internal routines, or how long the code is.

 

Anyway, I generated a ZIP file for the entire project. The should include all the source code and the buildlog.htm

0 Kudos
6 Replies
Highlighted
New Contributor I

Anyway, just to elaborate, I

Anyway, just to elaborate, I KNOW WHAT is wrong with the file it is reading in.

The germaine issue here is - why does the little green arrow point to line 13 of the calling routine, and not to anywhere in the routine itself?

The routine name is INPUT, BTW, as it says in the output pane. But I cannot examine any of the variables in the INPUT routine,

because that is not in the calling stack.

 

Problems like this are much easier to trace if we can get remote assist, instead of someone saying "well it works on MY computer, so you must be doing something stupid."

0 Kudos
Highlighted
New Contributor I

Also, when I insert a

Also, when I insert a breakpoint in the actual routine, then that works -

The problem occurs when the breakpoint is caused by an out-of-range subscript.

If no one wants to take a serious look at this, I may gave to file a formal complaint.

0 Kudos
Highlighted

Your ZIP omits all the source

Your ZIP omits all the source code.

Retired 12/31/2016
0 Kudos
Highlighted
Valued Contributor II

I am not really sure what you

I am not really sure what you have a problem with. When the program stops because of a run time exception it is often some time after the event that is the root cause. It will often be necessary to restart the program with some strategicly placed break points or conditional break points that allow you to home in on the problem. 

0 Kudos
Highlighted
New Contributor I

I am not sure how to include

I am not sure how to include the source code -

I could try again.

 

anyway, the germaine issue is (again) -

The little green arrow is supposed to point where the problem actually occurred, and it does not.

 

I am supposed to look at the variables within the routine that causes the problem, and I cannot do so.

So evidently there is a BUG either in the way the compiler sets up the breakpoints in that routine, 

or there is a BUG is the way VS interfaces with the code that causes the problem.

How would I buy a more up to date VS to see if I get the same result? It might have been fixed already.

 

I can pay for a support ticket, so that someone can do a remote assist, if need be.

How would I arrange for that ?

0 Kudos
Highlighted
New Contributor I

well, at least the output

well, at least the output pane shows where the run-time error occurs, so it is narrowed down somewhat.

 

I am just trying to avoid having to run the darn thing twice - - 

0 Kudos