22

Possible Duplicate:
What is the difference between a segmentation fault and a stack overflow?

I was just wondering, why stack overflow results in segmentation fault instead of stack overflow.

Is it because the boundary of stack limit is crossed which causes SIGSEGV? Why we don't encounter stack overflow in Linux, and rather a segmentation fault?

int foo()
{
  return foo();
}

This small code should cause stack overflow but rather it causes segmentation fault in Linux.

Community
  • 1
  • 1
RajSanpui
  • 11,556
  • 32
  • 79
  • 146

2 Answers2

12

A stack overflow can cause several different kinds of hardware errors.

  • It may lead to an attempt to access memory for which the program has no appropriate permissions → the kernel will raise a SIGSEGV (segmentation violation) signal for the process.
  • It may lead to an attempt to execute an illegal instruction (e.g: you overwrote the return address to point to an invalid instruction) → the kernel will raise a SIGILL (illegal instruction) signal.
  • Probably SIGBUS on some platforms (e.g: alignment exception).

All these errors occur after the stack overflow. An option is to add stack overflow protections (ProPolice, ...), so as to catch stack overflows before they cause more serious problems.

Edit:

You mean a "real stack overflow". Well, this case is covered by SEGV (trying to access memory for which the process has no permissions), so it gets a SEGV, instead of special-casing every single case of the more general SEGV.

ninjalj
  • 42,493
  • 9
  • 106
  • 148
  • 1
    Is there no way to get "stack overflow" in Linux, unlike other platforms (at least for user convenience, as to one can differentiate as when he has done illegal memory access, and when there is a real stack overflow? – RajSanpui Aug 08 '11 at 18:19
  • It can also cause random misbehavior, if you overwrite some other object that is located adjacent to the stack in memory – Chris Dodd Aug 08 '11 at 18:22
  • 1
    @kingsmasher: you can look at the address that caused the SEGV and/or the value of %esp -- if it points at a stack guard page, you have some kind of stack overflow. In general its not a terribly useful thing to do, as there's no general way of recovering from a stack overflow short of killing the process – Chris Dodd Aug 08 '11 at 18:24
  • @Chris: Thank you, that's a nice hint to understand. But unfortunately there is no straight forward error message. – RajSanpui Aug 08 '11 at 18:27
  • @kingsmasher1: well, I actually debug all SEGV's the same, and it would work equally well for stack overflow: look at the offending instruction, and look at the registers that are used as memory references there. – ninjalj Aug 08 '11 at 18:44
  • @Chris: Are you sure? Unlike other causes of SIGSEGV, it seems like stack overflow is rather safe to recover from via `longjmp`, assuming the code that was executing is safe to `longjmp` out of to begin with... – R.. GitHub STOP HELPING ICE Aug 08 '11 at 22:40
4

Stackoverflow is not an error, it is a case, the error thrown from it changes from language to language and from platform to platform.

See more about segmentation fault in wiki

EDIT:

To make it clearer - in your case, the call stack is overflowed and the program tries to write the next call to an invalid address, causing a segmentation fault.

MByD
  • 135,866
  • 28
  • 264
  • 277
  • But SIGSEGV results when access permission on memory is violated, which in no way is related to stack overflow, right? It is not about the error message only i guess, but most importantly the error message should indicate the type of error, which in above case is misleading. – RajSanpui Aug 08 '11 at 17:40
  • Sure it is related, the stack is not just an idea, it is a stack in the memory, and you overflows it, reaching an invalid addresses. – MByD Aug 08 '11 at 17:41
  • 2
    But the stack could be overflown although a segfault not yet occured, when the containing segment is bigger than the stack. – Nobody moving away from SE Aug 08 '11 at 17:43
  • @MByD: At google it says: `Another example is recursion without a base case, which causes the stack to overflow which results in a segmentation fault.[2]` it does not specify the reason as to why one error leads to anotherone. – RajSanpui Aug 08 '11 at 17:43
  • @Nobody: Excellent point Nobody. – RajSanpui Aug 08 '11 at 17:44
  • The stack is **not** in memory, it is a CPU register(s). – Justin M. Keyes Aug 08 '11 at 17:45
  • @Justin: No! The only thing regarding the stack in the CPU is the ESP(and EBP) that points to the stacks top. (And maybe values loaded from the stack). Or do you mean the floatingpoint stack? – Nobody moving away from SE Aug 08 '11 at 17:46
  • @Justin M. Keyes - most CPUs don't have enough registers to hold the call stack of the smallest program. – MByD Aug 08 '11 at 17:47
  • @MByD: most probably a SEGV occurs because some pointer/index on the stack got overwritten with bogus values, not because the overflow reached out of the stack. – ninjalj Aug 08 '11 at 18:07
  • @Nobody: I was thinking of the stack pointer. – Justin M. Keyes Aug 08 '11 at 18:19
  • @kingsmasher1: the stack is a piece of memory in which items are stored at the stack pointer and the stack pointer is moved up (or down) accordingly. If the stack pointer goes over the borders of the segment reserved for the stack, pushing om the stack means writing in memory that doesn#t belong to the stack and you get a segmentation fault (or whatever it is called on your OS). Some CPUs will be able to detect a stack overrun when then stack pointer is moved beyond itslimits, and then you get a stack overflow before you get the chance to write to "foreign" memory and cause a segfault. – Rudy Velthuis Aug 08 '11 at 18:51
  • But on https://en.wikipedia.org/wiki/Category:Computer_errors . **stack overflow** is in the error list. – Chen Li May 08 '18 at 07:35