for example, my code is :
int main(){
f();
g();
while(1){
h();
}
..
}
I set break point on f, g. of course, the program will stop at f()/g(), but when I type "c" and then it will keep running. currently I have to type "CTL+C" to stop it. program also be killed.
is there any other graceful ways to exit from gdb without killing program if the program is running?
thanks
I have to type "CTL+C" to stop it. program also be killed.
type "CTL+C" then gdb will catch SIGINT, then type detach and then "Ctrl-D" or quit. gdb will detach from you process and exit. Your program will go on running and its parent process will become init (PID=1)
Update:
(gdb) info signals SIGINT
Signal Stop Print Pass to program Description
SIGINT Yes Yes No Interrupt
Related
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 having a tough time figuring this one out; I have a program, iverilog that executes a system() call to invoke another program, ivl. I want to debug the second program, ivl in gdb, but I can't get gdb to set any breakpoints in the child process when I invoke gdb with the parent process. Here's what the programs look like:
//iverilog-main.cpp (Parent process)
int main(){
//...
system("ivl arg1 arg2");
//...
return 0;
}
.
//ivl-main.cpp (child process)
int main(){
//...
//stuff I want to debug
//...
return 0;
}
.
The gdb commands I'm running are: gdb iverilog -x cmds.gdb
# cmds.gdb
set args hello.v
set follow-fork-mode child
set breakpoint pending on
break ivl-main.cpp:main
run
Unfortunately, gdb doesn't break at ivl-main.cpp:main,it just completes without ever breaking; the output I get is:
Starting program: /usr/local/bin/iverilog hello.v
[New process 18117]
process 18117 is executing new program: /bin/dash
[Inferior 2 (process 18117) exited normally]
I'm certain ivl-main.cpp:main is being called because when I run the ivl program in gdb it successfully breaks there.
My thinking is that gdb doesn't recognize ivl-main.cpp as a source file when its running gdb iverilog, and it's not setting that breakpoint when it enters the child process which does contain ivl-main.cpp as a source file. So I think if I set the breakpoint for ivl-main.cpp when gdb enters the child process, it should work. The only way I can think of doing this is to manually break at the system() call and step into the child process, then set the breakpoint. Is there a more elegant approach that would force gdb to break whenever entering a child process?
Normally GDB only debugs one process at a time- if your program forks then you will debug the parent or the child, but not both simultaneously. By default, GDB continues debugging the parent after a fork, but you can change this behavior if you so desire with the following command:
set follow-fork-mode child
Alternately, you can tell GDB to keep both the parent and the child under its control. By default GDB only follows one process, but you can tell it to follow all child processes with this command:
set detach-on-fork off
GDB refers to each debugged process as an "inferior". When debugging multiple processes you can examine and interact each process with the "inferiors" command similar to how you would use "threads" to examine or interact with multiple threads.
See more documentation here:
https://sourceware.org/gdb/onlinedocs/gdb/Forks.html
This answer provides one way to achieve what you want.
In theory, set follow-fork-mode child should work.
In practice, the iverilog is likely itself a shell script that runs (forks) multiple commands, so at every fork you will need to decide whether you want to continue debugging the parent or the child. One wrong decision and you've lost control of the process that will eventually execute your program. This very likely explains why it didn't work for you.
I am working on a project in which there is a main program which runs in an infinite loop and executes the command given into terminal and will exit the loop on "exit command". This main program is not at all related to GTK. Now i have implemented a command for this main program which initiates a gtk application. Now the problem is that my main program get hang up and is not processing further commands till the GTK application is running.This is obvious because on starting application we starts a GTK main loop which only exit on closing the application.
So is there anyway so that my Gtk application will start in new terminal and allow my main program to process further commands?
Thanks in advance.
I don't know anything about GTK specifically, but generally you may want to run your command polling loop in a different thread of execution than your eventhandler Gui.
You can execute a task on a new thread using the thread facilites in the standard library like this:
// Example function.
void func(int arg1, double arg2) {
/* Do something... */
}
int main() {
std::thread t{func, 1, 2.0}; // Call func with args in new thread.
/* Continue doing things in current thread. */
t.join(); // Wait for thread to finish before exit.
}
Make sure to synchronize access to any data used by both threads.
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.
I'm debugging a C++ app for Ubuntu 10.04 that sometimes receives a SIGKILL signal.
I want to catch the signal and stop it from killing the execution, just to see if I can get some useful info of the app's state at that precise moment.
Reading the gdb documentation I found the handle command, so I tried to apply it to the SIGKILL signal:
(gdb) handle SIGKILL stop nopass
Signal Stop Print Pass to program Description
SIGKILL Yes Yes No Killed
So, as I understand this correctly:
stop
GDB should stop your program when this signal happens. This implies the print keyword as well.
print
GDB should print a message when this signal happens.
nopass
GDB should not allow your program to see this signal.
once the SIGKILL signal is emitted, gdb should somehow catch it, print the message, stop the execution and don't let the app kill itself, right?
The problem is that this doesn't happen and the app terminates.
Do you know how could I catch the signal?
Useful Info:
The piece of code that is running when the signal is emitted is executed in another thread.
gdb version: 4.4.3
g++ version: 7.1
From unix signal(7) man page:
The signals SIGKILL and SIGSTOP cannot be caught, blocked, or ignored.
So the debugger can set the handler but that doesn't make any sense. The OS directly performs the needed action. If SIGKILL could be handled from application the OS has no chance to terminate a broken application. For that reason SIGKILL is a bit special :-)