bug: Segmentation fault

Segmentation fault；

possible reasons:

 

 

What is a segmentation fault?

Ask Question

Asked 9 years, 5 months ago

Active 5 months ago

Viewed 524k times

 

514

 

247

What is a segmentation fault? Is it different in C and C++? How are segmentation faults and dangling pointers related?

c++ c segmentation-fault

shareimprove this question

edited Jun 1 '16 at 2:40

 

Jonathan Leffler

588k9797 gold badges709709 silver badges10611061 bronze badges

asked Feb 27 '10 at 9:23

Rajendra Uppal

8,2301111 gold badges4949 silver badges5656 bronze badges

• 75

  segmentation fault makes the compiler feel bad. – Benjamin Crouzier Sep 12 '11 at 14:32 

• 20

  If that's the case, why in my case the compiler complained nothing, it all went smooth, but at run time the system throws a segmentation fault (core dump)? T_T – Jim Raynor Jan 5 '15 at 19:46

• 3

  Just a memory dump when something goes wrong! – resultsway Apr 25 '15 at 1:18 

• 6

  @pinouchon: Funny, but when does a compiler have a thing to do with seg faults? Isn't it more the run time enviroment? – dhein Jul 30 '15 at 13:23

• 1

  Typically called by attempting to dereference a null pointer, so a segmentation fault is often analogous to a Java NullPointerException. – Raedwald Dec 18 '17 at 9:08 

add a comment

12 Answers

activeoldestvotes

603

 

Segmentation fault is a specific kind of error caused by accessing memory that “does not belong to you.” It’s a helper mechanism that keeps you from corrupting the memory and introducing hard-to-debug memory bugs. Whenever you get a segfault you know you are doing something wrong with memory – accessing variable that has already been freed, writing to a read-only portion of the memory, etc. Segmentation fault is essentially the same in most languages that let you mess with the memory management, there is no principial difference between segfaults in C and C++.

There are many ways to get a segfault, at least in the lower-level languages such as C(++). A common way to get a segfault is to dereference a null pointer:

int *p = NULL;
*p = 1;

Another segfault happens when you try to write to a portion of memory that was marked as read-only:

char *str = "Foo"; // Compiler marks the constant string as read-only
*str = 'b'; // Which means this is illegal and results in a segfault

Dangling pointer points to a thing that does not exist any more, like here:

char *p = NULL;
{
    char c;
    p = &c;
}
// Now p is dangling

The pointer p dangles because it points to character variable c that ceased to exist after the block ended. And when you try to dereference dangling pointer (like *p='A'), you would probably get a segfault.

shareimprove this answer

edited Feb 27 '10 at 10:23

aib

34.9k1010 gold badges6464 silver badges7474 bronze badges

answered Feb 27 '10 at 9:36

zoul

80.4k3838 gold badges226226 silver badges328328 bronze badges

• 141

  The last example is particularly nasty, when I build: int main() { char *p = 0; { char c = 'x'; p = &c; } printf( "%c\n",*p); return 0; } With either gcc or several other compilers, it 'appears' to work. No warnings on compile. No segfault. This is because the '}' out of scope, doesn't actually delete the data, just marks it as free to be used again. The code can run fine on a production system for years, you alter another part of the code, change compiler or something else and BOOOOOM! – Chris Huang-Leaver Apr 13 '10 at 9:06 

• 30

  Sorry for the bump but just a side note... none of your examples necessarily cause a segfault, in fact it's just undefined behavior ;-) – oldrinb Sep 15 '12 at 3:01

• 15

  @oldrinb: It is impossible to write code that necessarily causes a segfault. Not least because there are systems out there that operate without memory protection, thus cannot tell whether a piece of memory actually "belongs to you", and thus don't know segfaults, only undefined behaviour... (classic AmigaOS, for example)– DevSolar May 29 '14 at 18:03 

• 6

  @ChrisHuang-Leaver, you need to understand that c is local, it means that it have been pushed on the stack after { and pop-ed out of it after }. the dangling pointer is just a reference to an offset which is now out of the stack. that's why modifying it in a simple program will never trigger any segfault. on the other hand it may lead to segfault in a more complex use case, where other function calls might lead the stack to grow and contain the data pointed to by the dangling pointer. writing to that data (local vars) would lead to undefined behavior (segfault &Co) – Ayman Khamouma Jan 19 '16 at 21:23 

• 3

  @ChrisHuang-Leaver, normally when you get out of scope, the compiler has to recover some stack space to free the unused stack space, but this doesn't happen always (with gcc being one of this compilers). Also, the allocated stack space is normally reused again, so I have heard of no operating systems that return unused stack pages to the system, making that space subject for a SIGSEGV, so I won't expect such a signal from mangling with the stack. – Luis Colorado Jul 22 '16 at 11:59

show 3 more comments

104

 

It would be worth noting that segmentation fault isn't caused by directly accessing another process memory (this is what I'm hearing sometimes), as it is simply not possible. With virtual memory every process has its own virtual address space and there is no way to access another one using any value of pointer. Exception to this can be shared libraries which are same physical address space mapped to (possibly) different virtual addresses and kernel memory which is even mapped in the same way in every process (to avoid TLB flushing on syscall, I think). And things like shmat ;) - these are what I count as 'indirect' access. One can, however, check that they are usually located long way from process code and we are usually able to access them (this is why they are there, nevertheless accessing them in a improper way will produce segmentation fault).

Still, segmentation fault can occur in case of accessing our own (process) memory in improper way (for instance trying to write to non-writable space). But the most common reason for it is the access to the part of the virtual address space that is not mapped to physical one at all.

And all of this with respect to virtual memory systems.

shareimprove this answer

edited Mar 10 '12 at 21:58

answered Jul 3 '11 at 23:22

konrad.kruczynski

38.4k66 gold badges3131 silver badges4343 bronze badges

• With shared memory/memory mapped files it is possible for someone else to mess with your memory. In WIN32 there are nasty API's like 'WriteProcessMemory' too! – paulm Feb 17 '14 at 23:46

• 1

  @paulm: Yes, I know. This is what I had on mind in "And things like shmat ;) - these are what I count as 'indirect' access." – konrad.kruczynski Feb 18 '14 at 10:08

• In a virtual memory operating system there's no way (normally, so please, operating system implementors, don't flame me for this) for a process to access another process virtual memory, not being some kind of memory attach system call that allows you to access. Virtual memory addresses normally mean different things depending on the process being considered. – Luis Colorado Jul 22 '16 at 12:02

add a comment

32

 

A segmentation fault is caused by a request for a page that the process does not have listed in its descriptor table, or an invalid request for a page that it does have listed (e.g. a write request on a read-only page).

A dangling pointer is a pointer that may or may not point to a valid page, but does point to an "unexpected" segment of memory.

shareimprove this answer

answered Feb 27 '10 at 9:27

Ignacio Vazquez-Abrams

608k110110 gold badges11041104 silver badges11951195 bronze badges

• 9

  This is true, but would it really help you if you already didn’t know what a segmentation fault is? – zoul Feb 27 '10 at 9:37

add a comment