I need to debug a program which segfaults at uneven intervals. The program has a while(true) loop.
While debugging via GDB, it stops and asks for the Enter key to be pressed to continue. However, I want the program to run until it crashes. How do I do that in GDB?
Use set height 0 or set pagination off. Reference
Related
I know how to create/modify a breakpoint to stop only on a specific thread using breakpoint modify <breakpoint-id> -T <thread-name>, but can I do it the other way around, preventing the breakpoint to stop on a specific thread?
I have a log thread that use the same function I'm trying to debug on other threads and it's annoying to have to let it continue every time it hits.
You can do this sort of thing using the lldb Python API and Python breakpoint callbacks. The callback returns a "should stop" value, i.e. if it returns True, you stop at the breakpoint, and False you continue.
So for instance:
(lldb) breakpoint command add -s python -o 'return frame.thread.name != "MyThread"'
is what you wanted. Note, in this example, I didn't provide a breakpoint ID. In lldb that means "act on the last set breakpoint". But you can also supply the breakpoint ID if the one you want to add the command to doesn't happen to be the last breakpoint you set. And if you want to add it to multiple breakpoints, you can specify a breakpoint ID list.
There's more on the API's and the callback format here:
https://lldb.llvm.org/python_api.html
https://lldb.llvm.org/use/python-reference.html#running-a-python-script-when-a-breakpoint-gets-hit
Note, however, that breakpoints with should-stop callbacks will force a stop every time the breakpoint is hit. lldb auto-continues pretty quickly, so for many applications this isn't a problem. But just getting from the stop over to the debugger and back is not cheap, so if your breakpoint is in a work loop and getting hit hundreds of thousands of times a second, this is going to slow down the run. If that ends up being a problem and you control your source code, tricks like the one Eljay suggested in the comments can be really handy.
If I run a program under gdb, how do I break at an arbitrary point? Pressing Ctrl+C kills the program. Ctrl+Break does nothing.
I can't enter gdb commands because my program is itself sitting in a REPL loop so anything I enter goes to my program, not to gdb.
My program uses linenoise to implement the REPL; I assume that this is hiding Ctrl+C, etc., from gdb.
Ctrl+\ results in a 001C square blob thingy in my program, rather than SIGUSR1.
Pressing Ctrl+C kills the program.
That is not the default GDB behavior.
Did you set handle SIGINT nostop pass?
You can examine current signal disposition with:
(gdb) handle SIGINT
Signal Stop Print Pass to program Description
SIGINT Yes Yes No Interrupt
Update:
My program is using linenoise for console input. I assume that it has done something to Ctrl+C
If your program is modifying terminal settings, you are going to have a very bad time debugging it from the same terminal.
For example, suppose the program sets no echo, and then hits a breakpoint. I think you would get a (gdb) prompt, but would not see any commands you are typing into GDB.
It seems that you would be much better off debugging this program from a different terminal. Use gdb -p $PID to attach to it from "outside".
I'm trying to set breakpoing (break ) after attaching to process in background mode (attach &). However I got
Cannot insert breakpoint 1.
Cannot access memory at address 0x5560c872b71a
Any reason why it's happening?
Setting breakpoint in foreground mode is fine.
Program was written in C++.
Any reason why it's happening?
The program must be stopped when inserting a breakpoint into it. Inserting a breakpoint is not an atomic operation, and writing to program code (which is what breakpoint insertion amounts to) while that code is executing may result in all kind of badness.
Use interrupt command to stop the process and bring it to foreground, insert your breakpoint, then continue & to put it into background again.
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?
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.
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...
Rather than using Control-C to stop your program, you should use a breakpoint in lldb. When you attach to your program, before starting execution, you can set a breakpoint by typing:
break foo.c:11
to break in the file foo.c on line 11. See the docs for more information.
Once the debugger stops at the breakpoint, you can examine variables and perform other actions, then type:
continue
to continue the execution of the program.