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.

[jimdempseyatthecove]

Are you debugging the Debug build? (no optimization)

Try enabling the runtime check for index out of range.

Can you paste what you see in the output pane?

Jim Dempsey

[Steven_L_Intel1]

When you get the breakpoint for the subscript error, it should be stopping at the line of code in question. You might have to use the call stack dropdown to get to your code, but typically I don't see that. If you're running under the debugger, this should all happen automatically.

If not, then you need to make sure you have Traceback enabled so that it will tell you the line number. This is default in a Debug configuration.

[WSinc]

Oh, well it tells me the LINE number, and it DOES give a traceback, no problem there - - 

But That's in the OUTPUT pane.

But the problem is when I try to use the the DEBUGGER windows to look at contents of variables,

that might be leading up to the problem (in the subroutine windows).

shouldnt I be able to put the cursor on a variable name to look at what is stored there?

shouldn't it give an indication in a subroutine window where the breakpoint occurred?

I CAN do it if I use the F9 key to stop the code, (the little red dot)

but I CANNOT do that when the breakpoint is caused by an UNEXPECTED error.

Unfortunately, a printout wont really show the problem...........

Maybe a screen shot could ?

[Steven_L_Intel1]

As I said, it breaks in the debugger so you have access to variables. It is not clear to me what you are seeing. You do need to start the program under debug control to get this behavior.

[WSinc]

As I keep saying (over and over) I do NOT have access to the variables.

I always run it under the debugger control.

For smaller code amounts, the problem goes away.

[Steven_L_Intel1]

If you can provide a zip of a project that has this problem - please do a Build > Clean first - we'll look into it. It's supposed to work.

[WSinc]

Well, now when I run it , I am getting the little green arrow, like I am supposed to -

Do you have any ideas why its behavior would not be consistent?

I am afraid that when I send you the project, it wont be the SAME environment, so you wont see

the problem that I see (about half the time).

I cant figure out what triggers this - - - other processes, perhaps ? An anti-virus ?

Of course if you have a REMOTE ASSIST, then I could use that WHENEVER I get the problem on MY system.

A 64 bit system might give completely different results - - -

[Steven_L_Intel1]

I don't know why it would be inconsistent - sorry.

[WSinc]

We should be able to isolate this problem in OUR environment.

It is pointless to send you the project, and then have someone say - - 

"oh, there is nothing wrong."

Maybe  I should file a formal complaint - -

If I cant get remote assist?

[Steven_L_Intel1]

Remote assistance is not part of our typical support. Sometimes we'll do this if there's a serious problem we can't solve another way. I'm willing to schedule a time next week to try this and see if the problem can reproduce while I'm watching, but it isn't an "on call" sort of thing. Send me an email at steve.lionel at intel dot com with your availability next week - include your time zone - and I'll suggest a time mutually available.

[WSinc]

I think I have isolated the problem a little better.

where we see the difficulty is when the breakpoint occurs in assembly code.

In that case, the arrow points to the place in the assembly code, and then

the variables we want to look at aren't there. I am talking about where its at

a library subroutine. Of course, I can still look at the traceback in the OUTPUT

window. But then I would like to see the variables (and their contents) that lead up to that.

I guess then I would have to move the stack down?

I still dont get the little green arrow, though ? But at least I know where it occurred.

[WSinc]

OK, I ran a little test -

I deliberately FORCED a read error, and got the error message, but the

arrow pointed to the LIBRARY routine dis-assembly.

When I move the stack up, I still cant get the contents of the variables in the calling routine.

i.e the drop down window where you see the calling order.

so it appears to be an interaction between the Fortran library routine and the Debugger.

I dont know if this was addressed later, perhaps with a later debugger?

[Steven_L_Intel1]

I am not aware of any changes here. I use the debugger a lot, and when a breakpoint happens inside a library routine (so that I see assembler), I can always use the Call Stack to view local variables in my code. This isn't under control of Fortran, really - it's fundamental debugger behavior. Do you have a test program that always has the behavior you describe?

[mecej4]

A lot of ground has been covered in this thread, but it struck me that perhaps some points have not been taken into account.

When a breakpoint has been reached, one may examine variables belonging to the current routine or any routine that is in the stack chain from the main program to the current routine, provided that all these routines were compiled with debug support enabled.

If the breakpoint is within a library routine, it is quite likely that neither the source code nor the symbol information for the library routine are available, so examining variables belonging to the library routine is not possible at the source level. You probably do not want to examine these variables, anyway, unless you are debugging someone else's library routine.

Even when a breakpoint has been reached in one of your own routines, you will not be able to view the local symbols of another routine that is not currently in the stack chain, even if that routine has been exercised earlier in the run. In other words, you cannot view variables of routines after having returned from them (I am assuming that none of them is recursive).

[WSinc]

OK, well now when I run it,

I get the yellow arrow in the disassembly of the library routine (which I should)

but when I look at the stack frame, I get a comment "symbols are not loaded for libifcore.dll"

and then none of my routines are listed in the stack frame. Just a whole pile of library routines,

a couple of dozen in fact.

So there is no way to look at the variables in any of my routines, calling or otherwise.

[WSinc]

The results seem to be different at different times, so

if I send the project to YOU, you probably wont get the same thing

in YOUR environment.

[Steven_L_Intel1]

I don't see any evidence that a breakpoint was encountered (from an error or a user-set breakpoint). Did your program actually start to execute? The name of pre_cpp_init suggests that you're still in initialization code and your main program hasn't even started.  What happens if you set a breakpoint at the first executable statement and select Debug > Start (or press F5)? 

[WSinc]

Oh sure, this came from a read error in my subroutine - READIN. I deliberately put in a glitch in the input file so that it would trap in a library routine. And the output pane says "conversion error, LGU 1" But that is not in this screen shot I sent.

Isnt that little yellow arrow pointing inside a library routine? I guess it isnt, but that's WRONG, since a library routine triggered this breakpoint.

Why isn't the yellow arrow INSIDE the library routine? and why does it say "void" for the address?

I could run it again, and this time show the output pane - - -

anyway, if you look at that dropdown stack, you dont see any of my coded routines, just a lot of stuff that I can't figure out.

pre-cpp-init should be in the call stack anyway, would it not, since it starts my main program anyway ?

[Steven_L_Intel1]

I was able to reproduce what you are seeing with an example of my own, now that I have an idea of what your program does. We could have gotten here much sooner if you had sent a project earlier as I asked. I'm not sure why you didn't want to do that.

Here's a workaround - change the project property Fortran > Libraries > Use Run-Time Library to "Multithreaded".

I don't know what changed that is blocking the debugger from seeing your code, but will escalate this to the developers.

[WSinc]

well, the major issue is :

some of these problems are triggered by whatever environment I am working in - i.e.

a) what version of Visual studio

b) what version of windows

c) Is it 32 or 64 bit

d) what other processes are running concurrently,

e Is an anti-virus running concorrently

so if I send to you, how do you duplicate that same environment ?

several times in the past, i have sent a project, and what i get back is:

"there is nothing wrong with it" because they did not have the same environment I did.

It seems that only a remote assist would duplicate that - -