Locate the source code when a process crashes in Linux

A few days ago, the leaders arranged a small project to solve the problem: In Linux, the process may crash due to various reasons. at this time, we need to find the source code of the problem in the specific row number of a file, in this way, debugging will be convenient and efficient, and may be used by company projects ,... information &
A few days ago, the leaders arranged a small project to solve the problem: In Linux, the process may crash due to various reasons. at this time, we need to find the source code of the problem in the specific row number of a file, in this way, debugging will be convenient and efficient. it may be necessary for the company's projects. it is interesting to think about it. In addition, it took two or three days to solve the problem, of course, our leaders call it an expert who has given me a lot of advice. below are the ideas and steps for solving the problem and some of my own ideas. the general idea of www.2cto.com to solve the problem is as follows: in Linux, when a process crashes, the kernel (the so-called operating system) sends a signal to the process. for example, when the program crashes, we often see information such as segmentation falt, this is because the process operates the memory illegally and the kernel sends a SIGENV signal to the process. so why can we find the source code location corresponding to the cause of the process crash? we know, each process has its own stack. when a process crashes, some key information is stored in the stack. To the wrong source code location, how can we obtain the stack information when the process crashes? remember that Linux is the most powerful operating system in the world today (whether you believe it or not, I believe it, ^ _ ^). In Linux, there is a backtrace function that can obtain the current stack information. well, the problem has been solved in half, there is an address in the backtrace information that contains the offset of the error code in the file www.2cto.com. Note that the-g and-rdynamic parameters must be added during compilation. if we use a static library or an error occurs the code is not in the dynamic library, then we can use the command "addr2line-e executable file name offset address" to print out the wrong code line, the following figure shows the specific steps to operate the memory illegally on 29 lines of the test program. We put the addr2line command in the program and can see it in the code. The following figure shows the program output, we can see that the number of lines with errors in the printed source code is 29. if the crash is in a dynamic library so, it is a little more troublesome. in this case, addr2l Ine cannot directly provide code lines. As we all know, the address in so can be reallocate when the executable file is loaded. Therefore, if there is only one so address and the corresponding code line needs to be found, the parameter address sent to addr2line is an offset address, here, the offset address is the address in backtrace minus the base address when the dynamic library is loaded. we can find this base address through the/proc/pid/maps file. The pid is the current process number, the following are the specific steps, which are similar to the previous steps. for test purposes, we compile the func function into a dynamic library. here we only provide the test file. how can we implement the dynamic library, this is very easy. I will not mention it here. Below is a part of the test program. we will find the base address for loading an erroneous dynamic library in the/proc/pid/maps file, you can subtract the backtrace address from the base address to get the offset address. The program output shows that we use hello. c dynamic library, locate the code error in hello. the fifth line of c