GDB debugging multi-process programs

Gdb debugging multi-process Programs

Programs often use Fork/exec to create multi-process programs. Multi-process program has its own independent address space, which is the primary attention of multi-process debugging. GDB is powerful and provides a lot of support for debugging multithreading.

Method 1: Debug multi-process the most soil method: Attach PID

Attach is a common way to debug a process, as long as there are executable programs and the corresponding PID, you can work. Of course, for the convenience of debugging, you can set the sleep period after the process starts, such as 30s, so that there is ample time to attach.

To find the process ID:
Ps-fu Your_user_name
Run GDB:
Gdb
(GDB) Attach xxxxx ---xxxxx process ID for the subprocess obtained with the PS command
(GDB) Stop ---This is important, you need to pause that subprocess first, then set some breakpoints and some watch
(GDB) Break PNs --in result = WIB (value, div); This line sets a breakpoint, you can use the List command to view the source code
Breakpoint 1 at 0x10808:file eg1.c, line 37.
(GDB) continue
Continuing.

Method 2:set Follow-fork-mode Child + main breakpoint

When setting the set Follow-fork-mode CHILD,GDB executes the child process directly after the fork, knowing that the breakpoint has been hit and stopped. How do I set breakpoints for a child process? In the parent process, the address space of the child process cannot be known (only when the program is loaded). GDB provides a convenient mechanism: the breakpoint of the main function inherits the quilt process (after all, main is the entrance to any program).

Note: After the program stops in main, you can try to set a breakpoint. Whether the breakpoint is valid depends on whether GDB has loaded the address space of the target program.

Method 3:set Follow-fork-mode child + catch exec

The cache point is a special breakpoint. GDB can catch a lot of events, such as Throw/catch/exception/syscall/exec/fork/vfork and so on. One of the most process-related relationships is the Exec/fork event.

Example:

GNU gdb Fedora (6.8-27.EL5)

Copyright (C) Free Software Foundation, Inc.

(GDB) Catch exec

Catchpoint 1 (EXEC)

(GDB) Set Follow-fork-mode child

(GDB) r-d * * *

Catchpoint 1 (EXEC ' d/****/binary), 0x0000003c68800a70 in _start ()

From/lib64/ld-linux-x86-64.so.2

(GDB) bt

#0 0x0000003c68800a70 in _start () from/lib64/ld-linux-x86-64.so.2

#1 0x0000000000000003 in?? ()

#2 0x00007fff65c6e85a in?? ()

#3 0x00007fff65c6e85d in?? ()

#4 0x00007fff65c6e860 in?? ()

(GDB) B lib.cc:8720

No symbol table is loaded. Use the "file" command.

(GDB) C

Continuing

(GDB) bt

#0 0x0000003c68800a70 in _start () from/lib64/ld-linux-x86-64.so.2

#1 0x0000000000000002 in?? ()

#2 0x00007fff1af7682a in?? ()

#3 0x0000000000000000 in?? ()

(GDB) B lib.cc:8720

Breakpoint 2 at 0x15f9694:file lib.cc, line 8720.

(GDB) C

Continuing.

[Thread debugging using libthread_db enabled]

[Thread 0x40861940 (LWP 12602) exited]

[Switching to process 12630]

0x0000003c6980d81c in Vfork () from/lib64/libpthread.so.0

Warning:

Cannot insert Breakpoint 2.

Error accessing memory address 0x15f9694:input/output error.

(GDB) bt

#0 0x0000003c6980d81c in Vfork () from/lib64/libpthread.so.0

#1 0x000000000040c3fb in?? ()

#2 0x00002adeab604000 in?? ()

#3 0x01000000004051ef in?? ()

#4 0x00007fffff4a42f0 in?? ()

#5 0x686365746e6f6972 in?? ()

#6 0x0000000d0000000c in?? ()

#7 0x0000000b0000000a in?? ()

#8 0x0000000000000000 in?? ()

(GDB) Delete 2--here when breakpoint is invalid, it must be deleted or the program cannot continue

(GDB) C

Continuing.

[New Process 12630]

Executing new program:/****/binary

Warning:cannot Initialize thread debugging Library:generic error

[Switching to process 12630]

Catchpoint 1 (EXEC ' d/****/binary), 0x0000003c68800a70 in _start ()

From/lib64/ld-linux-x86-64.so.2

(GDB) bt

#0 0x0000003c68800a70 in _start () from/lib64/ld-linux-x86-64.so.2

#1 0x0000000000000009 in?? ()

BackTrace stopped:previous frame inner to this frame (corrupt stack?)

(GDB) B lib.cc:8720

Breakpoint 4 at 0x15f9694:file lib.cc, line 8720.

(GDB) B type.cc:32

Breakpoint 5 at 0x1693050:file type.cc, line 32.

(GDB) C

Continuing.

(GDB)--As with normal program debugging

Description: After the catch exec, the program will stop at Fork/vfork/exec. Not every time you stop, setting breakpoints is valid. If you provide an invalid breakpoint, you need to delete it, or the program cannot continue. To be able to set breakpoints in a new process, be sure to wait until the new process's address space is loaded and set the breakpoint to be valid (exec will change the address space of the original program). The above example, the main want to show how to set breakpoints on the new process!

Attention:

1) Program address is very important (Code and data address are as important). When using GDB, take a lot of attention and take advantage of address information.

2) on some systems, when a child process isspawned by vfork, you cannot debug the child or parent until an exec Callcomplet Es.

Method 4:info Inferiors/inferiors inferiors

Sets the set Detach-on-fork Off/set follow-exec-mode new.

If you choose Toset ' detach-on-fork ' mode off, then GDB would retain control of all forkedprocesses (including nested forks ). You can list the forked processes under Thecontrol of GDB by using the info-inferiors command, and switch from one fork to Another by using the inferior command.

GDB debugging multi-process programs