Mysterious PAUSE statement - how to track it?

[WSinc]

When I was running my program, I kept getting a PAUSE. I have to enter a CR to keep going.

So I did a global search to try to determine where in the code it was placed. But all of the PAUSE statements had a
text string after them, so were not the one causing the problem.

So I then did a CLEAN and rebuild. But the PAUSE statement was still there.

It DOES respond to a Ctl-C. But then I don't know how to get a line number where the Ctl-C interrupted the program. It just gives me a disassembly, but no identifying labels. The call stack does not point to it either.

Is there a way to track it from the CTL-C interrupt?
Do you have any idea how the PAUSE would get into my code?

Thanks; Bill

[TimP]

If you compiled and linked with traceback, and the stack still does not show where it was called, your program may be corrupting the stack. The next question would be whether you have tried running with all the check options, including interfaces.

[WSinc]

Quoting - tim18

If you compiled and linked with traceback, and the stack still does not show where it was called, your program may be corrupting the stack. The next question would be whether you have tried running with all the check options, including interfaces.

The TRACEBACK works fine with regular errors (such as overflow), but it does NOT trace back a Ctl-C interrupt.

Maybe that's because the CTl-C came from the KEYBOARD INPUT and not from the code itself.
The Ctl-C interrupt does not appear to point to anything in the USER code.
How do I make it tell me where IN THE CODE it was when the Ctl-C occurred?

[jimdempseyatthecove]

Quoting - billsincl

The TRACEBACK works fine with regular errors (such as overflow), but it does NOT trace back a Ctl-C interrupt.

Maybe that's because the CTl-C came from the KEYBOARD INPUT and not from the code itself.
The Ctl-C interrupt does not appear to point to anything in the USER code.
How do I make it tell me where IN THE CODE it was when the Ctl-C occurred?

Try this,

Insert into your program an explicit PAUSE.
Place breakpoint on that pause
At break, open Dissassembly window,
Step into PAUSE statement (F11 through and into call statement).
When at 1st statement after call, set break point.
Now F5 to continue deeper into PAUSE for your PAUSE.
Press Enter to continue from your PAUSE
You now should experience a Break at the next PAUSE.
Look at the call stack.

Jim Dempsey

[Steven_L_Intel1]

Or try this.

Run your program under the debugger. When the mysterious PAUSE hits, press the pause button in the debugger tool bar (||). After a few seconds, you'll get a message that "the process appears to be deadlocked". Click OK. The program will then break and the call stack will appear. A few lines in will be the call to _for_pause and then after that the identity of the code that called it.

or this:

Debug > New Breakpoint > Break at function
Enter the name "_for_pause" (for IA-32), or "for_pause" for x64
Start the application.

When the PAUSE is reached, it will stop in the debugger.

[WSinc]

Quoting - jimdempseyatthecove

Quoting - billsincl

The TRACEBACK works fine with regular errors (such as overflow), but it does NOT trace back a Ctl-C interrupt.

Maybe that's because the CTl-C came from the KEYBOARD INPUT and not from the code itself.
The Ctl-C interrupt does not appear to point to anything in the USER code.
How do I make it tell me where IN THE CODE it was when the Ctl-C occurred?

Try this,

Insert into your program an explicit PAUSE.
Place breakpoint on that pause
At break, open Dissassembly window,
Step into PAUSE statement (F11 through and into call statement).
When at 1st statement after call, set break point.
Now F5 to continue deeper into PAUSE for your PAUSE.
Press Enter to continue from your PAUSE
You now should experience a Break at the next PAUSE.
Look at the call stack.

Jim Dempsey

I am afraid that doesn't work - - -
When it stops at the pause, I don't have an option to display the disassembly window.
When I enter F11, it looks for a console input, then steps over the PAUSE statement.
In other words, there is no way to put the breakpoint INSIDE the PAUSE statement assembly code..
If I could, it would work then of course.
Maybe if I used the HEX address?

[jimdempseyatthecove]

Quoting - billsincl

I am afraid that doesn't work - - -
When it stops at the pause, I don't have an option to display the disassembly window.
When I enter F11, it looks for a console input, then steps over the PAUSE statement.
In other words, there is no way to put the breakpoint INSIDE the PAUSE statement assembly code..
If I could, it would work then of course.
Maybe if I used the HEX address?

You forgot to set a break point at the PAUSE line in your code. i.e. break just before the PAUSE. Then open the dissassembly window, step into the call, then set an additional break at what is called. F5 to continue into the PAUSE, CR to exit the PAUSE, then on next break check call stack.

Should the compiler generate code that makes setting break on PAUSE statement problematic, then insert a CONTINUE infront of the PAUSE and break on that.

Use Debug | View | Dissassembly to open the dissassembly window

Note, F11 (step into) will step into the CALL in the dissassembly window but step over the call in source window. You must have the focus on the dissassembly window when F11-ing

Steve's suggestion might work too, provided the call stack isn't mung'd up due to stack frame not being preserved as you go deeper into the runtime system.

Jim Dempsey

[Steven_L_Intel1]

I tested both of my suggestions before posting.

[WSinc]

I tried it again -

When I put the break on the line before the PAUSE, it still does NOT give me a disassembly window.
Apparently (at least for me) the break occurs BEFORE the statement is executed.
I found that out by testing the variables, and looking for printout, etc.

I am trying to open "DEBUG | View | Windows," at least that's where I assume it would be found.

The only way I can get the disassembly window is to hit F11 after the breakpoint is reached.
But then it has jumped into the error handling routine, and NOT the code area I want to look at.

Is there there a way to get to get the HEX address of the PAUSE routine?
Maybe from a linker address?

In the meantime I will try Steve's approach.

BTW, I've noticed that when I change the interface to a subroutine or function, I get interface errors,
even when everything is consistent.

The only way to straighten it out is to do a CLEAN and a REBUILD.
I think it's related to the compilation ordering.
Was this ever corrected in later releases?

[Steven_L_Intel1]

The problem with the interface errors is that the bulld order does not take generated interface checking into account. This is something we're working on.

[WSinc]

Quoting - Steve Lionel (Intel)

Or try this.

Run your program under the debugger. When the mysterious PAUSE hits, press the pause button in the debugger tool bar (||). After a few seconds, you'll get a message that "the process appears to be deadlocked". Click OK. The program will then break and the call stack will appear. A few lines in will be the call to _for_pause and then after that the identity of the code that called it.

or this:

Debug > New Breakpoint > Break at function
Enter the name "_for_pause" (for IA-32), or "for_pause" for x64
Start the application.

When the PAUSE is reached, it will stop in the debugger.

Hi Steve;

Method #2 does apparently work fine - -

I tried method #1 - - But when I looked at the call stack, nono of the addresses had anything to do with the code I was interested in. It was in a routine called "unlock_fhandle," and the other addresses were places I did not recognize.

Interestingly, when I misspelled the name of the function, it still acted like it set a breakpoint there,
even though it actually did nothing.

Maybe this should be investigated?
Can I also get the HEX address from a linker load map?

Yours; Bill

[Steven_L_Intel1]

The inaction when the name was misspelled would be a Visual Studio thing - not much we can do about it. I've seen that myself.

When I tried #1, I saw my routine several lines down the stack frame list.

So, did you figure out where you were?