Shulou(Shulou.com)06/01 Report--

This article mainly introduces Linux how to use gdb to debug multi-process related knowledge, the content is detailed and easy to understand, the operation is simple and fast, has a certain reference value, I believe that after reading this Linux how to use gdb to debug multi-process article will have a harvest, let's take a look.

1. Gdb commonly used catalog table operation description l command is equivalent to list, listing the source code from the first line, repeating the last command break+ line number setting breakpoint break+ function name in the function entry point setting breakpoint r run program abbreviation into break view breakpoint information n single statement execution, next abbreviation c continues to run the program, continue abbreviation bt view function stack finish exit function Q exit gdb II. Multi-process debugging test code:

# include # include # include int main () {pid_t id = fork (); if (id = = 0) / / child {printf ("I am child, my id is:%d;my father id is:%d\ n", getpid (), getppid ());} else if (id > 0) / / parent {sleep (2); printf ("I am father:%d\ n", getpid ()) } else {perror ("fork error"); return-1;} return 0;} 123456789101112131415171819202122232425 by default, GDB will only debug the main process when debugging multiprocess programs. But GDB (> V7.0) supports separate and simultaneous debugging of multiple processes, in other words, GDB can debug multiple programs at the same time. You only need to set follow-fork-mode (default: parent) and detach-on-fork (default: on). Parenton only debugs the main process (only parent is debugged by default in this program) childon only debugs the child process parentoff to debug two processes at the same time, gdb and the main process. The child process block (blocking) debugs two processes at the same time at the fork location childoff, gdb and the child process. The main process block is set at the fork location as follows: show follow-fork-mode show detach-on-fork

Query the process being debugged: info inferiors shows that all inferior,GDB debugged by GDB will assign them ID. The process with * is the inferior being debugged. GDB records the execution status of each debugged program in a structure called inferior. In general, an inferior corresponds to a process, and each different inferior has a different address space. Inferior sometimes exists when the process is not started. ) switch the debugging process: inferior switches to inferior where ID is num for debugging.

Add a new debugging process: add-inferior [- copies n] [- exec executable], which can be assigned to the inferior executable with file executable. Add n inferior and execute the program as executable. If n is not specified, only one inferior is added. If you do not specify executable, the execution program is left blank, and you can use the file command to reassign the execution program when it is added. The inferior created at this time and its associated process are not started.

Remove-inferiors infno: delete an inferior with an infno number. If inferior is running, it cannot be deleted, so you need to kill or detach the inferior before deleting it.

Detach inferior: detach is the inferior of infno. Note that the inferior still exists and can be executed again with the run command

Kill inferior infno: kill without the infno number inferior. Notice that the inferior still exists and can be executed again with commands such as run.

three。 Multithreading debugging multithreaded code

# include # include void* start_routine1 () {printf ("I am a thread1, my tid is:%u\ n", pthread_self ()); return NULL;} void* start_routine2 () {printf ("I am a thread1, my tid is:%u\ n", pthread_self ()); return NULL;} int main () {pthread_t tid1; pthread_t tid2; pthread_create (& tid1,NULL, start_routine1, NULL) Pthread_create (& tid2,NULL, start_routine2, NULL); pthread_join (tid1,NULL); pthread_join (tid2,NULL); return 0;} 123456789101112131415161718192021222324 Note: when creating a thread, be sure to add-lpthread when compiling a link! Be sure to add-lpthreadflowers! Be sure to add-lpthreadbasket cards! Say important things three times, painful lessons on the operation chart.

In multithreaded programming, when we need to debug, sometimes we need to control some threads to stop at breakpoints and some threads to continue to execute. Sometimes you need to control the order in which threads run. Sometimes you need to interrupt one thread and switch to another thread. All of this can be achieved through gdb. GDB supports debugging multithreading by default, following the main thread and child thread block in create thread. Table of contents commonly used in multithreaded programming

The operation description info threads shows all the threads that are currently debuggable, and each thread will have an ID assigned to it by GDB, which will be used later in the operation of the thread. The thread that is currently being debugged is preceded by *. Thread ID switch the thread currently being debugged is the specified ID thread break FileName.cpp:LinuNum thread all all threads have breakpoints in the LineNum line of the file FileName.cpp thread apply ID1 ID2 command lets one or more threads execute the GDB command commandthread apply all command allows all debugged threads to execute the GDB command commandset scheduler-locking off/on/step whether or not other threads execute when modulating one thread. Off, does not lock any threads, default. On, locks other threads, and only the current thread executes. Step, when step (single step), only the debugged thread runs. Set non-stop on/off whether to run set pagination on/off when one thread is modulated, whether to stop set target-async on/ff synchronization and async when paging when using backtrace. In synchronization, gdb waits for the program to report some information that the thread has terminated before printing the prompt. The asynchronous one returns four directly. When it comes to corecore, it means core, dumped means throwing, dumping, and core dumped means core dump. When a process exits abnormally, the process will throw out the memory details of the program process at that time and store them on the hard disk. The file name is usually core, which is called core dump.

The abnormal termination of a process is usually due to the existence of BUG in the code, such as a segment error caused by illegal memory access. You can use the debugger to check the core file to find out the cause of the error, which is called post-mortem debugging.

Instructions for core:

Instruction description uname-a view machine parameters ulimit-a view the default parameter ulimit-c 1024 set the core file size to 1024ulimit-c unlimit set the core file size to infinitely modify the ulimit setting and let it generate.

The instruction description ulimit-c 1024 sets the core file size to 1024. If the core file is larger than 1024 blocks, it will not be generated. Ulimit-c unlimit sets the core file size to unlimited. That's all for the article "how Linux uses gdb to debug multiple processes". Thank you for reading! I believe you all have a certain understanding of "how Linux uses gdb to debug multiple processes". If you want to learn more, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.