How to Use Gdb to Debug a Running Process

Can I use GDB to debug a running process?

Yes. Use the attach command. Check out this link for more information. Typing help attach at a GDB console gives the following:

(gdb) help attach

Attach to a process or file outside of GDB.
This command attaches to another target, of the same type as your last
"target" command ("info files" will show your target stack).
The command may take as argument a process id, a process name
(with an optional process-id as a suffix), or a device file.
For a process id, you must have permission to send the process a signal,
and it must have the same effective uid as the debugger.
When using "attach" to an existing process, the debugger finds the
program running in the process, looking first in the current working
directory, or (if not found there) using the source file search path
(see the "directory" command). You can also use the "file" command
to specify the program, and to load its symbol table.

---

NOTE: You may have difficulty attaching to a process due to improved security in the Linux kernel - for example attaching to the child of one shell from another.

You'll likely need to set /proc/sys/kernel/yama/ptrace_scope depending on your requirements. Many systems now default to 1 or higher.

The sysctl settings (writable only with CAP_SYS_PTRACE) are:

0 - classic ptrace permissions: a process can PTRACE_ATTACH to any other
    process running under the same uid, as long as it is dumpable (i.e.
    did not transition uids, start privileged, or have called
    prctl(PR_SET_DUMPABLE...) already). Similarly, PTRACE_TRACEME is
    unchanged.

1 - restricted ptrace: a process must have a predefined relationship
    with the inferior it wants to call PTRACE_ATTACH on. By default,
    this relationship is that of only its descendants when the above
    classic criteria is also met. To change the relationship, an
    inferior can call prctl(PR_SET_PTRACER, debugger, ...) to declare
    an allowed debugger PID to call PTRACE_ATTACH on the inferior.
    Using PTRACE_TRACEME is unchanged.

2 - admin-only attach: only processes with CAP_SYS_PTRACE may use ptrace
    with PTRACE_ATTACH, or through children calling PTRACE_TRACEME.

3 - no attach: no processes may use ptrace with PTRACE_ATTACH nor via
    PTRACE_TRACEME. Once set, this sysctl value cannot be changed.

How to attach a process in gdb

Try one of these:

gdb -p 12271
gdb /path/to/exe 12271

gdb /path/to/exe
(gdb) attach 12271

How can you debug a process using gdb without pausing it?

There's no way in gdb to attach without some sort of pause.

The Linux kernel provides some support for this via PTRACE_SEIZE, but gdb doesn't use this yet. There's a bug in bugzilla you can track, "Bug 15250 - use PTRACE_SEIZE and PTRACE_INTERRUPT"

Meanwhile you could try setting gdb into "observer mode". Then you could attach and use continue & to continue the process in the background. You may need to set various settings, like target-async, depending on the gdb version.

I am not totally certain if this will work. It is worth a try. Note that there is a window in which the program will be paused. This is unavoidable right now.

How to use GDB to debug a big project?

You can either debug an application by starting it with GDB

%> gdb <your_executable>

or what is usually easier is to start your application and then attach the debugger to the process using the PID.

%> gdb -p <pid>

For command line options, just type gdb -h and while running inside of gdb
help is always available by typing "help" on the gdb command line.

Here is a quick cheat sheet and a tutorial site on some common commands.

As Arkaitz mentioned, be sure to compile your code so that it has the necessary debug information included in the executable.

If debugging from the command line is a bit daunting, there are some UIs available that use GDB. I do a lot of my debugging in Eclipse using gdb.

Once you get started down the gdb path, I'm sure you'll have more questions and I encourage you to ask those more specific questions on SO.

Good luck.

Qt using gdb to debug an attached process

Since T created by forking from L. The gdb settings 'set follow-fork-mode' needs to be set to 'child' in Qt creator.

reference:
https://sourceware.org/gdb/onlinedocs/gdb/Forks.html

How to debug using gdb?

Here is a quick start tutorial for gdb:

/* test.c  */
/* Sample program to debug.  */
#include <stdio.h>
#include <stdlib.h>

int
main (int argc, char **argv) 
{
  if (argc != 3)
    return 1;
  int a = atoi (argv[1]);
  int b = atoi (argv[2]);
  int c = a + b;
  printf ("%d\n", c);
  return 0;
}

Compile with the -g3 option. g3 includes extra information, such as all the macro definitions present in the program.

gcc -g3 -o test test.c

Load the executable, which now contain the debugging symbols, into gdb:

gdb --annotate=3 test.exe 

Now you should find yourself at the gdb prompt. There you can issue commands to gdb.
Say you like to place a breakpoint at line 11 and step through the execution, printing the values of the local variables - the following commands sequences will help you do this:

(gdb) break test.c:11
Breakpoint 1 at 0x401329: file test.c, line 11.
(gdb) set args 10 20
(gdb) run
Starting program: c:\Documents and Settings\VMathew\Desktop/test.exe 10 20
[New thread 3824.0x8e8]

Breakpoint 1, main (argc=3, argv=0x3d5a90) at test.c:11
(gdb) n
(gdb) print a
$1 = 10
(gdb) n
(gdb) print b
$2 = 20
(gdb) n
(gdb) print c
$3 = 30
(gdb) c
Continuing.
30

Program exited normally.
(gdb) 

In short, the following commands are all you need to get started using gdb:

break file:lineno - sets a breakpoint in the file at lineno.
set args - sets the command line arguments.
run - executes the debugged program with the given command line arguments.
next (n) and step (s) - step program and step program until it 
                        reaches a different source line, respectively. 
print - prints a local variable
bt -  print backtrace of all stack frames
c - continue execution.

Type help at the (gdb) prompt to get a list and description of all valid commands.

How do I break into a running program using gdb?

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".

---

Related Topics