How do I track an infinite loop?

[WSinc]

Dear Dr. Fortran -

If I am debugging a Fortran program, and it appears to be "hung" in a loop, how do I find where the problem occurs? I don't get printout to help guide me.

If I use Ctl-C to stop it, it breakpoints, and I get a window with a lot of assembly code, but I don't get information as to where it was when I interrupted it relative to the actual source code, what subroutine, what line, etc.

Is there a way to interrupt it, and tell where it was, then continue onward? If I do this several times, I can then determne where the loop was.

Perhaps there is a way to set up a breakpoint handler for Ctl-C interrupts. Is there an article for that?

Thanks; Bill S.

[WSinc]

BTW, I did experiment with other "traps." It works fine for divide by zero, or FP overflow, etc. I get the line where it occurred, and it shows me the source code at that point.

The only one that gives me trouble is the Ctl-C traps mentioned above. Why do those behave differently?

I am trying to avoid sticking in a bunch of Print statements if possible.

[Steven_L_Intel1]

When it breaks, use the call stack pane (usually in the lower right) and you should see a call from your code somewhere down the list. Click on that entry and the source display will show you the offending point.

[jimdempseyatthecove]

Bill,

Most debuggers have a Pause button if your application was launced with debugger. The pause buttion in Visual Studio Debugger looks like || (pause key on video cassette recorder).

If not running from debugger, then most debuggers have an Attach to Process feature. You can use this to attach to a running process then press Pause (if it doesn't pause automatically).

Hopefully the hangup is in your application code.

However, if it is stuck inside a loop in a runtime libraryDLL then a stack trace may be hard to follow (as the stack frame is often not preserved into the DLL).You should be able to see the routine names in the DLL (if DLL has debug info). Knowing what was called may point you in the right direction into your code. The usual culprit of a hang inside a runtime library would be an interlock condition. Is your application multi-threaded?

Jim Dempsey

[WSinc]

Hi Jim and Steve;

Thank for your replies. I tried what you suggested - -

I get a call stack frame, but all the address are in HEX, so I don't know how to associate those with actual subroutine names and line numbers. This what I see:

>kernel32.dll!7c87534d()
[Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll]
kernel32.dll!7c87534d()
kernel32.dll!7c80b683()
kernel32.dll!7c875290()

-------------------------------------------------------------------------------------

Apparently there are no symbols for the kernel32.dll, that's the hangup.

Re: the Pause button, I tried that, but it is ignored unless I press the CTL key at the same time. Then it behaves just like the Ctl-Cinterrupt I mentioned earlier, but it says "Control Break interrupt" instead.

I guess without the debug symbols I would have to delve into a memory storage map to see what the HEX addresses correspond to. How do I generate said storage map? Thedisassembly does not give line addresses though, so it still could be tedious.

BTW, this is a simple non-threaded application.

Thanks; Bill S.

[jimdempseyatthecove]

Calls into kernel32 can go very deep. You should have a scroll elevator button on the call stack sub-window. Scroll down (drag down) to the bottom. You should see some of your code names at the bottom of the stack.

The Pause button refered to is not the keyboard Pause button. Rather the button I referred to is a control button on the debugger window. This is the one with the two short vertical bars.

Jim Dempsey

[Steven_L_Intel1]

If all you see is kernel32.dll lines, then your code is not showing. What version of the compiler are you using? I know that some older versions had a run-time library that did not save the stack frame properly.