Why "no source code?"

[WSinc]

I am trying to debug a subroutine I just compiled.

It gives no error messages.

But when I run the the program, I get a breakpoint,

and it says "No source code available."

So there is a bad subscript, or something else, 

but there is nothing pointing to where it occurred.

Apparently when the breakpoint occurs in an imbedded routine, the debugger cant handle it,

like when I use "contains" for example.

We never had this problem before, 

so WHY do they keep putting in new ones?

[andrew_4619]

There is a toggle in VS to show the disassembly mixed with the source which sometimes 'just happens' for me. I normally just close that source window by clicking the source  window , and then when I step (f10) it redisplayed the source in normal debug mode. I think it happens when you have stepped out of a routine for which no source is available.  

[WSinc]

Well, the test case I sent has a very obvious source code line that generates an "out of array"

subscript reference. so I don't see why it would be "out of the source code."

I still have NOT figured out (and no one else seems to know or care) why sometimes I CAN get the

source code lines in the dis-assembly window. I have ALL the options turned on for that.

And then sometimes I DO NOT get the source code lines.

It appears to be a random event.

Does the F10 step only thru my source code lines, or does it also step thru machine code lines?

I will try playing with that.

[Steven_L_Intel1]

Bill,

It is not true that no one cares, but I have noticed that you often report "random" issues that are not readily reproducible, even by you. It makes me wonder if there's something peculiar to your system that is introducing these instabilities.

[andrew_4619]

If you set a break point on the first executable line in your code and then invoke debug when it breaks there do you get source or assembly? 

I do not know how familiar you are with the debugger function is VS, but if you right click on a source line the popup menu has options to set breakpoints. I would set some strategic break points in the code and use f10 (step over one line) f11 (step into routine), f5 (run to next breakpoint). You want to find what happens before it crashes not after. 

[FortranFan]

Steve Lionel (Intel) wrote:

Bill,

It is not true that no one cares, but I have noticed that you often report "random" issues that are not readily reproducible, even by you. It makes me wonder if there's something peculiar to your system that is introducing these instabilities.

Note someone who is programming in C/C++ and debugging in Visual Studio can encounter such problems too.

So another aspect to consider: many of these issues are not specific to Fortran or Intel Fortran compiler, but with Visual Studio itself which is a Microsoft product, it is a huge IDE with so many features, significant changes can occur in it in between versions, and it can be a very complex system for those who do not take the time to understand it thoroughly.  I don't think anyone should expect this forum to be the best place to learn about or resolve issues involving Visual Studio - whatever one finds here should be considered a bonus.  In the world-wide web out there, there is tons of help too.  

[WSinc]

Well, I cant help wondering why anyone would have a product that is vulnerable to such "random" occurrences.

All I can say is; I run the program and sometimes it works, then other times, without making ANY changes,

I get this "random" problem. Maybe triggered by something else going on in my particular computer?

If it was something I DID then I would take a different approach and avoid it later.

In physics we have the: "Schrodinger uncertainly principle."

I guess you can have that in an operating system too?

It would be called the "Gates Uncertainty Principle" perhaps?

I am NOT an expert in the use of VS 2010, that's why I am referencing this forum.