Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

Erroneous DEBUG behavior

WSinc
New Contributor I
341 Views

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
WSinc
New Contributor I
341 Views

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
WSinc
New Contributor I
341 Views

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
Steven_L_Intel1
Employee
341 Views

Your ZIP omits all the source code.

0 Kudos
andrew_4619
Honored Contributor II
341 Views

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
WSinc
New Contributor I
341 Views

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
WSinc
New Contributor I
341 Views

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
Reply