What can cause segmentation faults in C++? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. 开发者_StackOverflow社区 Closed 11 years ago.

I noticed there's not question with a list of common causes of segmentation faults in C++, so I thought I'd add it.

Naturally it's community Wiki, since there's no one correct answer.

I think this might be useful for newer programmers learning C++, feel free to close it if you disagree.

---

Segmentation fault is caused by bad accesses to memory, only if your OS has a MMU (Memory Management Unit). Otherwise, you won't get it but only strange behavior.

The virtual memory (the entire memory accessible to you = 2^(sizeof(pointer_type)*8) (ie: 2^num_bits_in_pointer_type)) is mapped to physical memory in units named pages or segments (paging superseded segmentation but they are still used).

Each page has some protection rights, if you try to read from a page with no-read access you'll get a segfault. If you try to write to a readonly location you'll get a SIGSEGV.

If you have an unitialized pointer and use it it may happen that it will point to another good location so you'll don't get a segfault. If you have a small array reading after it's bound may corrupt other memory areas if it doesn't get past the page boundary.

Also, since there are many pages, not all of them are really mapped. If you touch a non-mapped page you'll get a segfault. Actually, any access to a non mapped page will have to take into account copy on write, pages on swap, lazy loading, memory mapped files and other things. See this article on page fault handling, especially the second diagram there, posted here below too (but read the article for more explanations)

_{(source: champ at vistech.net)}

You are mainly interested in what happens in user space and all paths leading to SIGSEGV. but kernel space is also interesting.

---

Many of the ways to 'segfault' C++ aren't necessarily guaranteed to happen, in fact, that is the case with most of the examples posted here. It's merely good luck (or bad luck, depending on how you look at it!) if you can perform these operations without a segfault occuring.

That is actually one of the things in C++ that separates it from other languages; undefined behaviour. Whereas in Java or C# you might get an 'InvalidOperationException' or similar, which is guaranteed to happen when these operations are performed; in C++, the standard just says 'undefined behaviour', which is basically luck of the draw, and you never want that to happen.

---

Dereferencing NULL pointers.

#include <cstddef> //For NULL.
int* p1 = NULL; //p1 points to no memory address
*p1 = 3; //Segfault.

---

Accessing an array out of bounds (Possible):

int ia[10];
ia[10] = 4; // Someone forgot that arrays are 0-indexed! Possible Segfault.

---

A favourite of mine:

#include <iostream>
struct A {
    virtual void f() {
        std::cout << "A::f();\n";
    }
    int i;
};

struct B : A {
    virtual void f() {
        std::cout << "B::f();\n";
    }
    int j;
};

void seti(A* arr, size_t size) {
    for (size_t i = 0; i < size; ++i)
        arr[i].i = 0;
}

int main() {
    B b[10];
    seti(b, 10);
    b[3].f();
}

As with most things that can cause a segfault, this can also fail to fail. On ideone, for example, b[3].f() fails, but b[2].f() works.

---

The obvious answer is “undefined behavior”, but this begs the question for an unexperienced programmer, and some types of undefined behavior are much less likely to cause a segmentation fault (or another type of crash) than others. The most frequent causes of segmentation faults are generally pointer related: dereferencing an uninitialized pointer, a null pointer, or a previously freed pointer; accessing beyond the end (or in front of the beginning, but that's less frequent) of an object (array or other); using the results of an illegal pointer cast (static_cast to a derived type, when the object doesn't actually have that type, or most reinterpret_cast); etc.

Perhaps the most important point to keep in mind here, however, is that in general, these are not guaranteed to cause a segmentation fault, and that often, the segmentation fault that they cause will only occur sometime later, in a completely unrelated operation. Thus, writing beyond the end of a local array will usually “work”, but will modify whatever happens to follow the array on the stack: some other local variable (modifying the vptr of an object on the stack may lead to a segmentation fault when you attempt to call a virtual function on the object), the frame pointer of the calling function (which will probably cause a segmentation fault in that function, after you've returned), or the return address (which may cause all sorts of strange behavior—a segmentation fault or an illegal instruction trap are probably the best that can occur). Writing beyond the end of freed memory, or through an already freed pointer, can corrupt the free space arena, causing a segmentation fault in a much (sometime much, much) later allocation or free; it can also modify some other, totally unrelated object, corrupting its vptr or some other pointer in the object, or just some random data—again, a segmentation fault is probably the best possible result (far preferrable to continuing with corrupted data).

---

Trying to modify string literals:

char* mystr = "test";
mystr[2] = 'w';

This CAN cause segmentation fault.

---

Forgetting to initialize pointers, leaving them with random memory addresses. Note: this may not always segfault, but it could.

int* p1; //No initialization.
*p1 = 3; //Possible segfault.

---

Dereferencing freed memory could potentially cause a segfault.

SomeClass* someObject = new SomeClass();
delete someObject;
someObject->someMethod();  //Could cause a segfault.