How can I continue from a program that has stopped, using lldb?

Question

I am trying to break out of a read-line loop into lldb, and then continue where I broke out of. When I try using C-C, the program just exits after the "continue" command is given to lldb.

Here is the sample code:

#include<iostream>
#include<string>
using namespace std;
int main(){
  string cmd;
  while(true){
    if (!getline(cin,cmd)) {
      cout<<"ending on eof"<<endl;
      break;}
    else if (cmd=="GO INTO DEBUGGER"){
      //??
    }
    else 
      cout<<"Got line: "<<cmd<<endl;
  }
  cout<<"Exiting program"<<endl;
  return 0;
};

When this program is executed, it just echoes back the input line. When I interrupt the program using C-C, I bounce back into the debugger. When I then execute "continue" in the debugger, instead of returning to the loop, I just exit with the EOF message.

How can I either return to the loop from when the loop was interrupted, either using C-C or perhaps by using some kind of command in place of the "GO INTO DEBUGGER" clause (returning from "assert(0)" rarely works I find.

This is all compiled with clang++ on Mac Mavericks.

Note: for some reason the lldb backtrace says it received SIGSTOP, I thought C-C was SIGINT, but I guess I'm out of date.

Answer 1

This sort of problem comes because of the interaction between signals and system traps. When a program that is sitting in a system trap waiting for input (or in any system trap really) gets a signal, the system may need to get the thread sitting on the trap out of the kernel in order to deliver the signal to it. If it has to do that, the trap call will return with an its usual error value, and the thread local "errno" variable will be set to EINTR.

This is happening to you in the debugger because the debugger has to send a signal (lldb uses SIGSTOP rather than SIGINT for uninteresting reasons) to interrupt your program.

However, this isn't specific to the debugger, this could happen because of job control signals or any other signal your program might receive. So to be safe, when you get an error return back from some read (read, select, getline, etc...) type call, you are supposed to check errno and only treat the error as an EOF if errno is not EINTR.

That being said, it seems like getline is buggy w.r.t. signals. If I interrupt the program while it is sitting in getline, I get a 0 return and errno is correctly set to 4. But the next time I call into getline, it again returns with 0, but this time errno has not been reset which makes it kind of hard to use in this context. Interesting...