Recently encountered in the project segmentation fault error, has been debugging does not come out where the problem, for just contact embedded, also do not know how to debug a project, positioning memory problems, tangled for several days, good red tidy up their own ideas. Start from the beginning.
The following content only for the collation of their own use, mostly from the network, thank you for sharing:
Http://www.cnblogs.com/no7dw/archive/2013/02/20/2918372.html
Http://blog.chinaunix.net/uid-20780355-id-538814.html
first, what is "segmentation fault in Linux"
a segmentation fault (often shortened TO SIGSEGV) is a particular error condition that can occur during the Operation Of c Omputer software. A segmentation fault occurs when a program attempts to access a memory location that it's not allowed to access, or Attem PTS to access a memory-in-a-allowed (for example, attempting-to-write to-a read-only location, or To overwrite part of the operating system).
Segmentation is one approach to memory management and protection in the operating system. It had been superseded by paging for most purposes, but much of the terminology of segmentation was still used, "Segmentati On fault "being an example. Some operating systems still has segmentation at Some logical level although paging is used as the main memory management Policy.
On Unix-like operating systems, a process this accesses an invalid memory address receives the SIGSEGV signal. On Microsoft Windows, a process of that accesses invalid memory receives the status_access_violation exception.
is: the so-called paragraph error refers to the memory of the access is beyond the system to the memory space given to the program, usually this value is saved by GDTR, he is a 48-bit register, of which 32 is saved by it points to the GDT table, the last 13 bits to save the corresponding GDT subscript, The last 3 bits include whether the program is in memory and the program's operating level in the CPU, and the GDT that points to is a table with 64 bits in one unit. In this table, you save the code snippet that the program runs and the starting address of the data segment, as well as information about the corresponding segment limit, the page exchange, the program run level, the granularity of the memory, and so on. Once a program has crossed access, the CPU will have the corresponding exception protection, so segmentation fault appeared.
That is, "when a program attempts to access an area of memory that is not allowed to be accessed (for example, trying to write a piece of memory that belongs to the operating system), or accessing the memory area with the wrong type (for example, try writing a piece of read-only memory). This description is accurate. In order to deepen our understanding, we will summarize the SIGSEGV in more detail. Segment error should be access to inaccessible memory, this memory area is either nonexistent or protected by the system.
ØSIGSEGV is an error that occurs when accessing memory, which belongs to the memory management category
ØSIGSEGV is the concept of a user state, which is the processing that the operating system makes when the user states the program incorrectly accesses memory.
SIGSEGV is generated when the user-state program accesses memory that is not allowed to be accessed (access indicates read, write, or execute).
Ø generates SIGSEGV when the user state program accesses the memory that is allowed to access in an incorrect manner.
A user-state program address space, especially a range of address spaces that a program can access. In a broad sense, the address space of a process should include the kernel space part, but it cannot be accessed.
Ii. possible circumstances arising from SIGSEGV
Pointer out-of-bounds and SIGSEGV are the most common cases, and often see a post confusing the two, and the relationship is really subtle. In this case, we have classified the cross-border, wild pointer, and null pointer that are caused by the pointer operation (plus minus) as the pointer crosses the bounds. SIGSEGV is often caused by pointers being out of bounds, but not all pointers out of bounds will cause SIGSEGV. An out-of-bounds pointer will not cause SIGSEGV if it is not used to refer to it. Even if you dereference a pointer that is out of bounds, it does not necessarily cause SIGSEGV. It sounds crazy, and it does. SIGSEGV related to the operating system, c libraries, compilers, linker aspects of the content, we have some specific examples to illustrate.
(1) The wrong type of access is causing
#include <stdio.h> #include <stdlib.h>int main () { char *c = "Hello World"; C[1] = ' H ';}
The above program compiles without problems, but the runtime pops up SIGSEGV. In this example, "Hello World" is a constant string that will be placed in the. Rodata section (GCC) after compilation and the last link to the target program. The Rodata section is merged into the text segment with the code snippet, so its memory area is read-only. This is the SIGSEGV caused by the wrong type of access.
(2) Access to memory that is not part of the process address space
#include <stdio.h> #include <stdlib.h>int main () { int* p = (int*) 0xc0000fff; *p = 10;}
There is another possibility to write data to a system-protected memory address, most commonly by giving a pointer to a 0 address :
int i=0;scanf ("%d", I); /* should have used &i */printf ("%d\n", I); return 0;
(3) Access to non-existent memory
The most common scenario is to dereference a null pointer, such as:
int *p = NULL;
*p = 1;
In practice, the null pointer in this example may point to the user-State address space, but the page it points to does not actually exist.
(4) memory out of bounds, array out of bounds, variable type inconsistent, etc.
#include <stdio.h>int Main () { char test[1]; printf ("%c", test[10]); return 0;}
This is the obvious array out of bounds, or the address does not exist at all.
(5) Attempting to output an integer as a string
int Main () { int b = ten; printf ("%s\n", b); return 0;}
What's the problem? Since I'm not yet familiar with debugging dynamic link libraries, I just found the source code for printf here.
Declaration section: int pos =0, cnt_printed_chars =0, I; unsigned char *chptr; Va_list AP;%s Format Control section: Case ' s ': chptr =va_arg (AP, unsigned char *); i = 0; While (chptr [i]) {... Cnt_printed_chars + +; Putchar (chptr [i + +]); }
? ? Look closely and find out that when you print a string, you actually print all the characters at the beginning of an address, but when you want to print the integer as a string, the integer is treated as an address, and printf starts to print the character from the address until the value in a position is. Therefore, if the integer represents an address that does not exist or is inaccessible, it is natural to access the memory--segmentation fault that should not be accessed.
? Similarly, there are format control issues such as sprintf, such as the attempt to output or store char or int as%s, as follows:
#include <stdio.h> #include <string.h>char c= ' c '; int I=10;char buf[100];p rintf ("%s", c); Attempt to output char type in string format, where the word inode is interpreted as an integer and then interpreted as an address, so the reason is the same as the above example printf ("%s", I); An attempt was made to output an int as a string (buf, 0, memset); sprintf (buf, "%s", c); Attempted to convert char type memset (buf, 0, +) in string format; sprintf (buf, "%s", I); Attempting to convert int type to string
(6) Stack overflow, sometimes sigsegv, sometimes nothing happened
? ? Most C language textbooks will tell you that when you return from a function, the contents of the stack are automatically "freed". "Release" to most beginners the impression is free (), it seems that the memory does not exist, so when he visited this should not exist in memory, found that everything is good, then fell into deep doubts.
third, debug positioning SIGSEGV
When you write a program in C + + language, most of the work of memory management needs us to do. In fact, memory management is a relatively tedious task, no matter how smart you are, the experience is rich, will inevitably make small mistakes here, and often these errors are so simple and easy to eliminate. But manual "Bug-Remover" (debug), often inefficient and annoying, uses GDB to quickly locate these "segment errors" of the statement. There are many other ways to do it. For some large-scale programs, how to track and find the segment error location in the program is a skill to grasp to pull.
1) output (printf) information in key parts of the program, so that you can track the possible location of a segment error in your code
In order to facilitate the use of this debugging method, you can use the conditional compilation directive #ifdef Debug and #endif the printf function to include, compile the time with the-ddebug parameter can see debugging information. Conversely, do not add this parameter to debug it can.
2) debugging with GdB , where it runs to the wrong segment, it automatically stops and displays the line and line number of the error
This should be very common, if you need to debug with GDB, remember to compile the time with the-G parameter, to display debugging information. GCC should all be installed.
Installing Gdb:sudo aot-get Install GDB First
The following is the debugging process for a small program:
When running GCC, add-G This parameter to view debugging information,
L: (list) show our source code
B line number: Set a breakpoint on the corresponding line, I set it on line sixth
R:run running programs to breakpoints
P:p (print) The value of the print variable
An error message appears in the next step of N: {(next)
C:continue Continue execution
Quit: Exit GDB
To prevent the appearance of segmentation fault should pay attention to:
1, define the pointer after the initialization, when used to remember to determine whether NULL
2, whether the use of the array is initialized, array subscript is out of bounds, array elements exist, etc.
3, in the variable processing time the variable format control is reasonable and so on
Segmentation Fault Error Causes summary