How to locate a problem without a core dump file

Recently developed on the Linux QT, found that the program exception crash, with the core dump file also did not record the useful information, the following figure:

Locator abnormal crash process of pain, although the final is to use the core dump file size limit cancellation, complete logging program crash stack information with GDB to locate the problem, but found that users share without core-dump location bug, so record down, for future trial.

Sometimes write a C + + program, run after the core, if there is a core file can gdb convenient positioning problem,

However, how to locate the core file when it is not found (or deleted).

Just did a test, in the absence of core files in the case of the bug to locate the program

Cat Core.cpp
1 #include <iostream>

2
3 int main (int argc, char** argv) {
4
5 int *p = NULL;
6 for (int i=0; i<15; i++) {
7 P[i] = i;
8}
9
Ten return 0;
11}

g++-G Core.cpp-o Core

./core

Segmentation fault

/var/log]# VIM messages

Nov 04:02:08 i237 syslogd 1.4.1:restart.
Nov 13:55:01 i237 kernel:testreg[19978]: Segfault at 000000000000000a RIP 00000036ED078D50 RSP 00007fffa7125888 Error 4
Nov 13:58:20 i237 kernel:testreg[20711]: Segfault at 00000000000003e8 RIP 00000036ed078d70 RSP 00007fff8e28ac98 Error 4
Nov 16:19:10 i237 kernel:core[17962]: Segfault at 0000000000000000 RIP 0000000000400677 RSP 00007FFF0C53DC30 error 6

The last core[17962] is the process that just generated the core

can go to this core.cpp to generate the core directory

Perform:

Addr2line 0000000000400677-e/path/./core

Output:
.../core.cpp:7

So we can initially locate the problem in the Core.cpp line 7th, and return to the program to see the assignment of the illegal address

Let's see the man Addr2line.

NAME
Addr2line-convert addresses into the file names and line numbers.

The command itself is the address of the name and line number, but we need to this address in the message log to see the RIP address to get

In addition, the number of the error after the conversion to the binary sequence corresponding description is as follows:

Bit2: A value of 1 indicates that the user state program memory access is out of bounds, and a value of 0 indicates that the kernel-state program memory access is out of bounds
Bit1: A value of 1 indicates that the write operation caused memory access to go out of bounds, and a value of 0 indicates that the read operation caused the memory access to go out of bounds
Bit0: A value of 1 means that there is not enough permission to access the contents of the illegal address, a value of 0 means that the illegal address of the access does not have a corresponding page, that is, invalid address

So from this error 6 You can also know the reason is that the user program operation accesses the bounds

Last encyclopedia to borrow a register:

Dedicated registers

Special registers include: RIP, RSP and Rflags as well as segment registers CS, DS, ES, SS, FS and GS.

RIP (instruction pointer) RIP addresses the next instruction in the code snippet store. When the microprocessor is working in real mode, the register is IP (16-bit) and the EIP (32-bit) when 80386 and higher microprocessors work in protected mode. Note that 8086, 8088, and 80286 do not contain EIP registers, and only 80286 and higher types of microprocessors can work in protected mode. The instruction pointer points to the next instruction in the program for the microprocessor to address the next instruction in the code snippet sequentially in the program. The instruction pointer can also be modified by a transfer instruction or call instruction. In 64-bit mode, RIP contains a 40-bit address bus that can be used to address 1TB flattened mode addresses.

RSP (stack pointer) RSP addresses a storage area called a stack. Using this pointer to access stack memory data, the specific operation will be explained later in this book to access the stack memory data instructions. This register is an SP when it is referenced as a 16-bit register, or ESP if it is a 32-bit register.

Original address: http://blog.csdn.net/cloudusers/article/details/16946285