I have a simple C program that forks a process and then runs an executable.
I want to attach the child process to gdb.
I run the main program in a console and open another console to find the pid of the child process, then I start gdb with the following command:
gdb attach 12271
where 12271 is the child process id, but the attach fails with:
No such file or directory.
Any idea why?
Try one of these:
gdb -p 12271
gdb /path/to/exe 12271
gdb /path/to/exe
(gdb) attach 12271
The first argument should be the path to the executable program. So
gdb progname 12271
With a running instance of myExecutableName having a PID 15073:
hitting Tab twice after $ gdb myExecu in the command line, will automagically autocompletes to:
$ gdb myExecutableName 15073
and will attach gdb to this process. That's nice!
Related
When I debug process with GDB I saw logs like:
[Detaching after fork from child process XXXX]
How can I stop print those log in gdb script?
Envirment is:
target:x86_64 client,runs the program which is striped
Host:x86_64 server ,has code,toolchain,striped program,symbles file for debug
run gdbserver on target:
%gdbserver --multi :1234 /pathtolog/gdb.log
run program on target:
./someprogram &
[1] PID
run gdb on host:
%gdb
(gdb)target extended-remote TARGETIP:1234
(gdb)file someprogram
(gdb)setrootfs pathtorootfs
(gdb)...//set lib path etc.
(gdb)attach PID
...//load everything as normal
...//stop somewhere
(gdb)c
^C^CThe target is not responding to interrupt requests.
Stop debugging it? (y or n)
tried to find the root cause:
on the target:
gdb attach to gdbserver(yes I can use gdb on the target right now,but the target machine shall be released without gdb,symbles,etc. for size).
(gdb) b kill
Breakpoint 1 at 0xf760afb0
(gdb) c
Continuing.
when press ctrl+c from host gdb ,gdbserver will break into the breakpoint
Breakpoint 1, 0xf760afb0 in kill () from /lib/libc.so.6
(gdb)
I'v checked register,the %esp register shows like this:
(gdb) x /32wx 0xffee8070
0xffee8070: 0xfffffe0c 0x00000002 0x00000001 0x00000000
0xfffffe0c = -PID
0x00000002 = SIGINT
some program will get the signalwhen gdbserver continue .
so，kill() is good for "SOME PROGRAM",not all.
And I'v use tcpdump monitored data between gdb/gdbserver.
If kill() worked （for "GOOD" program),gdbserver will send a packet to gdb.
I'v tried sigmonitor,found out gdbserver didn't send any sigal to "BAD program" in this case.but I can call kill(pid,2) int gdbserver debuging gdb process
(gdb) call kill(PID,2)
then dmesg shows like this
[11902.060722] ==========send_signal===========
SIG 2 to 6141[a.out], tgid=6141
...
SIG 19 to 6142[a.out], tgid=6141
[11902.111135] Task Tree of 6142 = {
...
Any ideas?
Found out a possible match bug of gdbserver.
parameter of kill() called by gdbserver is -PID,not PID.
gdbserver sends SIGINT not to the process, but to the process group (-signal_pid).
But the attached process is not always a process group leader.
If not, "kill (-signal_pid, SIGINT)" returns error and fails to interrupt the attached process.
static void linux_request_interrupt (void)
{
/* Send a SIGINT to the process group. This acts just like the user
typed a ^C on the controlling terminal. */
- kill (-signal_pid, SIGINT);
+ kill (signal_pid, SIGINT);
}
This problem remained in gdb-8.1,don't know why they don't think it's a problem.
I have a program running on a remote machine which expects to receive SIGINT from the parent. That program needs to receive that signal to function correctly. Unfortunately, if I run that process remotely over SSH and send SIGINT, the ssh process itself traps and interrupts rather than forwarding the signal.
Here's an example of this behavior using GDB:
Running locally:
$ gdb
GNU gdb 6.3.50-20050815 (Apple version gdb-1344) (Fri Jul 3 01:19:56 UTC 2009)
...
This GDB was configured as "x86_64-apple-darwin".
^C
(gdb) Quit
^C
(gdb) Quit
^C
(gdb) Quit
Running remotely:
$ ssh foo.bar.com gdb
GNU gdb Red Hat Linux (6.3.0.0-1.159.el4rh)
...
This GDB was configured as "i386-redhat-linux-gnu".
(gdb) ^C
Killed by signal 2.
$
Can anybody suggest a way of working around this problem? The local ssh client is OpenSSH_5.2p1.
$ ssh -t foo.bar.com gdb
...
(gdb) ^C
Quit
Try signal SIGINT at the gdb prompt.
It looks like you're doing ctrl+c. The problem is that your terminal window is sending SIGINT to the ssh process running locally, not to the process on the remote system.
You'll have to specify a signal manually using the kill command or system call on the remote system.
or more conveniently using killall
$killall -INT gdb
Can you run a terminal on the remote machine and use kill -INT to send it the signal?
I am trying to debug with gdbserver. after I terminat the gdb client on the host I see that the gdbserver is still listening :
Remote side has terminated connection. GDBserver will reopen the connection.
Listening on port 5004
I tried to exit gdbserver with everything I have found anywhere no luck: quit,exit,q, monitor exit,Esc,Cnt+c... nothing kills it. Moreover, when I opened another terminal and looked for the process running gdbserver (with the commands ps,top) I couldn't find it there...
my question is - How to terminate gdbserver ?
Give command
monitor exit
from your host gdb before terminating the client. If you have already terminated it, just attach with another one.
monitor exit step-by-step
https://stackoverflow.com/a/23647002/895245 mentions it, but this is the full setup you need.
Remote:
# pwd contains cross-compiled ./myexec
gdbserver --multi :1234
Local:
# pwd also contains the same cross-compiled ./myexec
gdb -ex 'target extended-remote 192.168.0.1:1234' \
-ex 'set remote exec-file ./myexec' \
--args ./myexec arg1
(gdb) r
[Inferior 1 (process 1234) exited normally]
(gdb) monitor exit
Tested in Ubuntu 14.04.
gdbserver runs on the target, not the host.
Terminating it is target dependent. For example, if your target is UNIX-ish, you could remote login and use ps and kill from a target shell.
For any type of target, rebooting should kill gdbserver.
(If this isn't enough to answer your question, include more information about the target in the question.)
on linux write:
ps -ef |grep gdbserver
Now find the pid of the gdbserver process and then
kill -9 <pid>
Here is a script which I'm using to start gdb server via ssh and kill it when necessary with ctrl+c
#!/usr/bin/env bash
trap stop_gdb_server INT
function stop_gdb_server {
ssh remote-srv-name "pkill gdbserver"
echo "GDB server killed"
}
ssh remote-srv-name "cd /path/to/project/dir/ && gdbserver localhost:6789 my-executable"
quit [expression]
q
To exit GDB, use the quit command (abbreviated q), or type an end-of-file character (usually C-d). If you do not supply expression, GDB will terminate normally; otherwise it will terminate using the result of expression as the error code.
gdbserver should exit when your target exits. The question is how your target is exiting: does it
do nothing: just fall through
return 0 in main
exit(0) in main
From the debug sessions I've been running, in the first case, gdbserver will not exit. It will just hang around forever and you have to kill it. In the latter two cases, gdbserver will exit.
Is it possible to generate a core dump without killing the process? If so, what is the command/signal to do so?
Thanks,
Jim
See the 'gcore' command, part of GDB.
I had the best success with attaching gdb in batch mode to the running program, get a backtrace and then detach.
gdb --batch --quiet -ex "set pagination off" -ex "thread apply all bt"
-ex "detach" -ex "quit" pid pid_of_process
A method to generate a coredump directly from program without gdb is described here:
https://unix.stackexchange.com/questions/11185/dump-process-core-without-killing-the-process
It make sense only if you are developing. Principle is to fork program and to raise SIGABRT from child.