Linux section Error Debugging method

1. If the crash is in the program, for example SMH kernel:process_name[32183]: Segfault at IP 0000000000412b13 SP 00007fffaab744e0 error 6 in Process_ NAME[400000+6E000]

1> can be addr2line-e process_name 0x412b13-f specific to the source of that line of that function.

2> can also navigate to specific functions by disassembling Objdump-dgs process_name > output and then searching for 412b13 in the output file.

2. If the program crashes in a shared library, for example process_name[10678]: Segfault at 1 IP 00007f6ddc43c650 SP 00000000461b41a8 error 4 in LIBC-2.4.SO[7F6DDC 3CA000+127000]

The actual address of the instruction is: 00007f6ddc43c650-7f6ddc3ca000 = 0x72650

1> can be addr2line-e libc-2.4.so 0x412b13-f specific to that function in libc-2.4.so.

2> can also navigate to a specific function by disassembling Objdump-dgs libc-2.4.so > output and then searching for 72650 in the output file.

3. Make some necessary explanations for the two examples above:

1> error code (such as Error 4 & Error 6 above) does some explaining: you can find it in/usr/src/linux***/arch/i386/mm/fault.c by searching for "Segfault at"

   /*
*Page faultErrorCode bits
      *Bit 0==0 means no page found,1 means protection fault
*Bit 1==0 means read,1 means write
      *Bit 2==0 means kernel,1 means user-Mode
*Bit 3==1 means use of reserved bit detected
      *Bit 4==1 means fault is an instruction fetch
*/

2. #define Pf_prot (1<<0)
4. #define Pf_write (1<<1)
6. #define Pf_user (1<<2)
8. #define PF_RSVD (1<<3)
10. #define PF_INSTR (1<<4)
14. 2> When the loader is loaded, if the shared library is in a dynamic link (and one that is dynamically loaded, linker & Dynamic Loader), the shared library is assigned an address space ( Each time the program executes the address is different). Therefore, the command address at the time of the crash is to subtract the base address of the shared library, which is the offset of the instruction. The example above is 00007f6ddc43c650-7f6ddc3ca000 = 0x72650
18. 3>. When the program crashes, there is no way to know which line of code in the source program is calling the interface in the library function that caused the program to crash, because the information about the register cannot be obtained, in other words, there is no way to know the address of the next instruction. To do this, we can still release the coredump switch, through the GDB process_name coredump to analyze (bad situation, stack frame is destroyed, we can do is to analyze the assembly instruction idea to restore the destroyed stack frame) , or in our source program by capturing the SIGSEGV signal, the stack frame information to print to the log file to analyze, with the GCC provided by the backtrace and Backtrace_symbol, if you want to print out the stack frame information contains the function name, Then we need to use the rdynamic option at compile time (notifies the linker to add symbols to the dynamic symbol table).

4>. Reference http://www.2cto.com/kf/201311/256739.html

Http://blog.chinaunix.net/uid-20357359-id-1963702.html

Http://www.xxlinux.com/linux/article/accidence/technique/20070125/7209.html

Linux section Error Debugging method