Q about debugging difficulty

[WSinc]

I am debugging a program, and I get a breakpoint, apparently because of an out-of-range subscript.

Anyway, when I open the relevant subroutine, isn't it supposed to SHOW me where the breakpoint occurred?

(It is mentioned in the OUTPUT pane.) but it doesn't show me where in the CODE listing.

I also wanted to put the cursor on some variables that would show me their contents

so I can track down why it occurred. But I don't get anything regarding what is stored in any of them.

I was hoping I would not have to insert a bunch of PRINT statements, and run it again, but the debugger will not reveal

what I need to look at.

any reason why this might be happening? Sometimes it works, but it fails when i have a routine with a lot of source lines in it.

[Steven_L_Intel1]

In this case, I would have been able to reproduce it. What I was missing was the nature of the error that triggered the breakpoint, since your initial problem statement was vague. I can reproduce the problem reliably across various versions of Intel Fortran, Visual Studio and 32/64 bit.

In the future, please provide a test project. Most of the time it will help us understand the issue and will save everyone a lot of time and aggravation. Issue ID is DPD200241761.

[mecej4]

Steve, I think that some of us would be able to benefit from examining the example that you created for the purpose of exhibiting the debugger problem(s) discussed in this thread.

[Steven_L_Intel1]

Very simple.

program U557388

    open (unit=1,file='U557388A.txt',form='formatted',status='old')
    !write (1,'(A)') 'XXX'
    !rewind(1)
    read (1,'(I3)') J

end program U557388

The commented out lines were to reproduce what Bill was doing (with 'replace' instead of 'old'), but the problem shows even without them (you get "file not found" in this version). When you build this program against the DLL libraries (which is the default now) and run it in the debugger, the program has disappeared from the stack frame when the exception triggers the debug breakpoint. If you build against the static libraries, it works the way it is supposed to. I have no idea why there is a difference.

What is maddening to me is that this problem was initially reported in 2013, but got misrouted so it was never seen by the right development team. I can't find any other reports of this, which is even more astonishing.

[WSinc]

OK, I can send the whole project -

but if you did NOT know HOW I did the build,

you would not be able reproduce the same problem, isn't that right?

In other words, wouldn't you have to know that I built it against the default DLL libraries.

That's possibly what happened before when I sent a project.

If I send the BUILDLOG along with the project, would that have all the complete information needed?

[Steven_L_Intel1]

I typically ask for a ZIP of the project, which includes the buildlog. If you sent the project, including the .sln and .vfproj files, I'd know how you built. But since DLL linking is the default, I would have tried that first anyway. If you had sent the project as you had it, I would have been able to reproduce the problem right away.