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

Answer 1

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.

Answer 2

Dereferencing freed memory could potentially cause a segfault.

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

Answer 3

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.

Answer 4

Accessing an array out of bounds (Possible):

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

Answer 5

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).

Answer 6

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.