I am running a fortran code. The code has no pauses nor any switches that ask user to do anything. It should run beginning to end with no stops. This is a code that has a big outer loop and several OpenMP inner loops. The only thing I output are the index of the bigger outer loop so that I can know where the code is.
The code usually runs with no problems. However, the last two times I run it, the code stopped with no error (I know that because the cores usage started being 0%). However if I press enter in the console the code resumes normally.
So my question, is there any way to pause a fortran code at run time without having an explicit pause on the code?
Do you have any READ statements in your program? They'd pause the terminal if they're waiting for input.
For example, the following program looks like it's pausing in the middle of the loop. Pressing enter allows it to continue.
integer i
do i = 1, 10
if (i == 5) read(*, *)
print *, i
end do
end
Perhaps you or someone else added a READ for debugging purposes and forgot to remove it?
Related
In a C++ application I have 2 threads (thread1 and thread2) from the same class. They are running a loop very fast and nothing should made any blocking calls inside the loop:
while (!end) {
//dostuff, no blocking!
}
cout << "ended" << endl;
There is some bug in the application, because when I run only one thread at a time, and I set its end property, it can quit from the loop successfully.
However, if I run both threads, sometimes one of the threads is not able to break out from the loop (in spite of having its end property set).
The loop itself is quite big (few hundred lines), I can put a (conditional)breakpoint into it, but when I'm stepping, I lose the functionality (as the thread should run fast), so even if I found which line blocks, it might be the wrong way.
So, my question: is there any option in gdb for having a breakpoint which behaves like a watchdog?
I.e: it should break the thread if withing a certain time it won't be hit, so I can check which line causes the trouble.
I.e: it should break the thread if withing a certain time it won't be hit, so I can check which line causes the trouble.
You don't need this functionality to check which line causes trouble (and the functionality doesn't exist).
Wait for the "not exiting" condition to happen, and hit Control-C. GDB will stop all threads of the process, and give you the (gdb) prompt. At that point, issue thread apply all where command, and you will see where the "not exiting" thread is stuck.
I have a loop which checks to see if a certain process is active. If the process isn't active, the main program launches it using the system() call. Example:
#define MODERATING_INTERVAL 1000
...
while (true) {
if (!isProcessRunning())
system("helper.exe");
Sleep(MODERATING_INTERVAL);
}
My problem is that everything runs fine, but the main program is paused as long as the helper.exeprogram is running, so the loop will not iterate.
I couldn't find a solution myself, so I'm asking: is it possible to make the example loop continue iterating while the invoked program is running?
Thanks in advance.
This is the normal behaviour of system. If you want to start a new process that runs concurrently with your current program you need to use CreateProcess.
So I feel that I am close to solving a programming assignment that takes the most used word of each line and prints it on a line. So for example:
I am a man, am right?
I don't know if i like that.
It's okay to not feel okay.
Would print: "am i okay" (punctuations and case are ignored for the assignment)
This is what I have done so far, but the problem is that the while loop that scans the lines never terminates and thus never prints the output in the external for loop. Anybody see where I went wrong?
string line;
vector<string> result;
while(getline(cin,line)){ //on each line
}
Your loop is correct as written; you just don't know how to signify the end of input. You're sitting there waiting for the program to progress, but the program is sitting there waiting for you to give it more input.
Press Ctrl+D (Linux) or Ctrl+Z (Windows) to send the EOF character/signal/potion to end the loop.
This way, all the common shell techniques like file redirection and pipes will also work.
Introducing artificial means like a double-newline or some magic command is non-conventional and makes your program harder to automate. (And making your program magically know that one of the newlines came from a keyboard hit rather than copy/pasting, is just not possible. Nor do you want it to be! That breaks a ton of valuable abstractions.) When writing a command-line tool, stick to standard practices as much as possible.
Currently your program is waiting for an EOF character which indicates the input has ended. If you are running this and entering the input from the command line, you can manually insert an EOF by pressing Ctrl+D on *nix, or Ctrl+Z on windows. This will cause your program to break out of your getline loop.
If you would rather not do that, you need a way to break out of the getline loop, otherwise it will continue to run in that loop.
A nice idea might be detecting an empty line, so pressing enter twice ends the loop:
while(getline(cin,line)){ //on each line
if(line == "")
break;
...
}
My Eclipse project is a C++ with makefile project. After at the end of the makefile, there is a call to the executable as if from terminal. (./myEXE)
This program is expected to accept commands from the terminal upon runtime (it is a physics simulation using MPI, with possibility to input "stop" or "stats" or "stop" commands while the simulation runs).
The input is written (not my original code) with a select() (from library sys/types, this for example) to see if there is anything readable from the stdin. The timeout option for select() makes sure MPI has time to start. After trying to read input for a while, it will check that the MPI workloads progress, and if they don't, it will raise timeout error.
Everything works like a charm when I call the makefile from terminal. It is broken when trying to run from Eclipse (shift+F9 and so on...)
It seems the problem is that stdin is always readable, thus checks on MPI before it has the possibility to initiate simulations - select() returns after <1ms.
My two main questions are therefore:
Where is Eclipse reading stdin from?
Why is it always readable?
P.S. Since the program is called via MPI in the makefile instead of directly from Eclipse, its a bit tricky to debug it all....
When select says stdin is readable, you must make sure to change its state before you call select again, otherwise it will just return immediately. Your code doesn't change its state but instead just calls select again, causing it to loop forever.
How you should fix it depends on whether stdin being closed is a fatal condition for your program. If your program must have a working stdin to continue, then if it gets an EOF while reading stdin, it should terminate, not just keep selecting blindly. If your program can continue to run usefully even without a working stdin, then it should take it out of its select set if it closes or errors. (Or stop calling select, depending on the logic.)
But you can't just ignore the case and keep running as if nothing happened.
During many, sometimes inundating, debugging sessions using DDD, I stumble upon loops. And I keep pressing next to get past it, and if there are many iterations, I just set a break point right after it, and press "continue." Is there any other way to go past loops?
You want the "until" command - see the gdb manual at http://www.gnu.org/software/gdb/documentation:
Continue running until a source line
past the current line, in the current
stack frame, is reached. This command
is used to avoid single stepping
through a loop more than once. It is
like the next command, except that
when until encounters a jump, it
automatically continues execution
until the program counter is greater
than the address of the jump.
This means that when you reach the end
of a loop after single stepping though
it, until makes your program continue
execution until it exits the loop. In
contrast, a next command at the end of
a loop simply steps back to the
beginning of the loop, which forces
you to step through the next
iteration.
I typically use the "continue until here" which sets a temporary breakpoint at that location and immediately continues execution. It is accessed via mouse button 3 which opens a popup menu.