Talk:Stack overflow

I've rewritten this article to expand it to include buffer overflows that have a security implication (as well as including the current content), you can see it here. It could use some other eyes (preferably eyes of someone that can spell) and could use some more sources, but all in all I think its a better article...I'm looking for comments, feel free to edit it in my sandbox for now and if there are no objectsion by, say, this time next week, I'll integrate the changes into the existing article... --Michael Lynn 08:38, 8 August 2007 (UTC)

stack buffer overflows are covered in depth elsewhere, while they're occasionally referred to as "stack overflows", I would argue that usage is incorrect. -- taviso 04:45, 9 August 2007 (UTC)

with all due respect, they are almost always called stack overflows, i call on you to find sources to the contrary as I've found more than a few in favor of my possition (not to mention my being a pretty well undisputed expert in the field myself (see Michael Lynn). --Michael Lynn 05:05, 9 August 2007 (UTC)

Michael, I remember your excellent IOS bugs, I work in the field myself. I'm sure you could find several examples of people misusing the term who don't understand the difference between infinite recursion and a buffer overflow, and I wouldn't object to that being documented. -- taviso 00:28, 10 August 2007 (UTC)

Incidentally, TAOCP3,v1,s2.2.2 defines Stack Overflow concisely, and uses the term several times. Redefining the term would be confusing, clearly the stack is not overflowing (the stack pointer isnt moving), where as "stack buffer overflow" makes sense, a buffer overflow, where the buffer is allocated on the stack. -- taviso 01:20, 10 August 2007 (UTC)

I wouldn't be 100% opposed to moving it to "stack buffer overflow", and I do understand where you are coming from, in a very technical sense of the term you are of course correct. That being said however, whenever someone refers to a "stack overflow" when they might otherwise have said "stack buffer overflow" it creates more confusion. If you take a look at the sources in my sandbox article you will find that the two terms are used interchangably throughout. I have more than one paper there that make reference to what you'd call "stack buffer overflow" as a "stack overflow" in the title of their paper. The reason I included the two meanings in one article (and you'll note that I did include the meaning you're refering to at the top of my version) is because, like it or not, the term "stack overflow" has come to also encompass stack buffer overflows as well. Would it perhaps be acceptable to you to keep them all in one article but to insert some wording to explain the difference in terms. All that said, while i prefer to keep it the way I've done it in my rewrite, its not completely out of the question to make a disambiguation page that would seperate the two articles. However if thats what we're going to do I'd like to maintain consitancy with other related articles, like heap overflow. If we change stack overflow to not include this meaning, we should also change heap overflow to be heap buffer overflow, as of course, you don't overflow the heap, but rather a buffer on it. I'm open to your suggestions. --Michael Lynn 02:13, 10 August 2007 (UTC)

As an "undisputed expert" in computer security, I'm sure you're exposed to lots of publications where "stack overflow" is used as an unambiguous contraction of "stack buffer overflow", I know I see this regularly so I completely understand where you're coming from. My argument is really that information security is such a narrow field, and the concept of a stack data structure is so fundamental to computer science that it's not acceptable to re-use our niche definition of the term in this sense. I don't object to using "heap overflow" as a contraction of "heap buffer overflow", as there is no collision.

Out of curiosity, how would you describe something like this?

void foo()
{
  stack_t s[100];
  value_t v;
  while ((v = getvalue()) != -1)
   push(&s, v);
}

"A stack overflow leading to a stack overflow"? Which is the real bug, the stack overflow or the stack overflow? (I'm just kidding :)) -- taviso 16:26, 10 August 2007 (UTC)

I don't feel that stack buffer overflows are niche or even seperate from computer science. Their exploitation to gain control of a vulnerable process surely is, but the concept of a stack buffer overflow is an extremely common source of memory corruption leading to crashes. The fact that they are exploitable does not take away from their signifigance in other contexts. What I'm worried about is that people looking for information about stack buffer overflows are going to be confused when they search for stack overflow and find no information about what they are looking for. Because most texts on the subject, especially introductory texts still refer (incorrectly or not) to stack buffer overflows as stack overflows. I think we either need the two combined or we need a disambiguation page. --Michael Lynn 22:38, 10 August 2007 (UTC)

Modified Proposal

ok, how is this for a compromise, we keep the existing article largely as it is (but including the sources I found in mine that are relevant to it) and place my article (minus the redundant parts) under the title of "Stack Buffer Overflow", then at the top of both articles we place the little "this article is about foo, to see the other topic, go to bar", that way we keep the article (both of them), and we avoid confusion from either side of this debate because both articles will provide a quick explanation that you might be looking in the wrong place, if so go the correct article...

If this proposal will work for you then I'll go ahead and merge in small extra part of my article that is relevant to the existing one and create a new article under the title of "stack buffer overflow" and put disambiguation linkage at the top of each article...is that compromise agreeable to you? --Michael Lynn 01:24, 11 August 2007 (UTC)

No objections here, sounds like a good idea to me. -- taviso 15:14, 11 August 2007 (UTC)

Ok then, I'll start making the edits and get it ready later today... --Michael Lynn 01:35, 12 August 2007 (UTC)

Jeff Atwood, Joel Spolsky, and StackOverflow.com

Is StackOverflow.com popular enough that it should have an article? I've heard people ask what Stack Overflow is (and not talking about what this article is about). Once it has an article, I guess a link to the article from this page or a disambiguation page would make sense. --Ben Atkin (talk) 18:05, 28 August 2008 (UTC)

You know, I think it is. Teemu Leisti (talk) 10:06, 6 June 2014 (UTC)

Oh, and I just noticed it has been done already: Stack Overflow, also redirected to from Stack Overflow (website). Teemu Leisti (talk) 10:08, 6 June 2014 (UTC)

changed bad wording

I have changed the previous incorrect wording to something a bit more correct. The claim stacks have a limited amount of "memory" is obviously completely wrong. In modern high end CPUs such as x86_64, address space is reserved for the stack, not memory. Memory is allocated from the page pool as required.

Additionally the claim overflow occurs when the stack uses too much memory is logically absurd. If the address space is limited you cannot use more memory than the allocated address space on the stack: it is the attempt to do so, not the impossible actuality of doing so, which leads to the stack overflow condition. This is true whether or not the machine issues a page fault, or actually allows the user to exceed he bound (the excess past the end of the stack in this case is not "in" the stack so it cannot be said to contain that memory).

I changed the wording to specify overflow occurs when the stack pointer exceeds the stack bound, which is a limit on its address space, however this is not really satisfactory either. In particular the Intel i64 has two stacks, and any program written in, say, C, can create a stack data structure.

In principle stacks are unbounded, however in practice there are bounds even on user defined stacks, and I believe this article does, reasonably, attempt to describe machine stacks, not user defined data structures. — Preceding unsigned comment added by Skaller (talk • contribs) 16:00, 29 May 2013 (UTC)

Proposed merge of "Stack buffer overflow" into "Stack overflow" (this article)

This article and Stack buffer overflow seem to be about the same thing. Is there any reason why they should not be merged? Peter Flass (talk) 12:59, 26 January 2014 (UTC)

They are not about the same topic. Both overflows are types of bounds violations. A stack overflow occurs when a program is attempting to use the stack, but instead accesses memory beyond the bounds of the stack. From reading the other article, it looks to me like a stack buffer overflow occurs when a program attempts to access a data structure located within the stack, but accesses memory beyond the bounds of the data structure. —Tanner Swett (talk) 21:19, 15 February 2014 (UTC)

It feels like splitting hairs to have two articles, both talking about computer science issues that are almost but not quite the same. The differences and subtleties could easily be noted in a single article IMO. Michaelward82 (talk) 14:53, 6 May 2014 (UTC)

"Stack buffer overflow" should not be merged into "Stack overflow". I came to this talk page because the template at the top of the article says that merging "Stack buffer overflow" into article Stack overflow is being proposed. As pointed out in the discussion far above (ending 12 August 2007), "stack overflow" means something different, that is, the condition when the memory reserved for a program's stack is exceeded. If "Stack buffer overflow" should be merged anywhere, it should be into the article Buffer overflow. Teemu Leisti (talk) 14:42, 29 May 2014 (UTC)

These are two VERY DIFFERENT things.

"Stack overflow" usually happens via operations that are all individually valid (push, call, allocate), but collectively use up the available, allocated stack space. On modern processors, stack overflow triggers an exception.

"Stack buffer overflow" (better-named "stack buffer overrun"), a type of "buffer overflow" (better-named "buffer overrun"), is a single errant operation caused by storing multi-byte data into an allocated multi-byte space (buffer) that is not long enough, which, due to lack of safeguards, silently malfunctions, overwriting adjacent memory cells that are allocated to other data, causing crashes or weird behavior, or facilitating execution of injected code or returns to injected addresses. (And don't forget buffer-read overruns, which can disclose random samples of data that should not be disclosed (Heartbleed).)

That they happen to sound alike is too feeble to justify a merger. The result would be crude, explaining two different kinds of malfunction that both involve the stack. I might merge "Stack buffer overflow" into "Buffer overflow" if I -just had to- merge something, but -never- into "Stack overflow".

"Oh, drat these computers, they're so naughty and so complex. I could pinch them." -(Marvin the Martian, circa 2453) WHY do we have to defend against the urge to oversimplify?

PS: Looking again at the jargony noun-noun-noun term, I noticed that "stack buffer overflow" is not guaranteed to parse correctly. I have to point out: "Stack buffer overflow" is not "overflow" of the "stack buffer" (no one even calls the stack the "stack buffer"); it is "overflow" of a "buffer" that happens to be on the "stack"! -A876 (talk) 05:00, 14 June 2014 (UTC)

Yes, these are quite distinct: different causes (overrun at the end of the stack usually caused by deep recursion versus a buffer overflow in the middle of the stack caused by insufficient bounds checking) and different effects (program crash versus exploitable security hole). A "stack buffer overflow" is always a kind of "buffer overflow", but does not necessarily cause a "stack overflow".

I can understand the confusion of non (systems) programmers, however, so the article should probably address this explicitly. I could not come up with a good way to phrase this, though. —Ruud 10:01, 17 September 2014 (UTC)

"Very deep recursion"

This section seems to suggest that a stack may be required to convert primitive recursion to a loop. It's my understanding that all primitive recursion can be converted to a loop without a stack. By my understanding, it's non-primitive recursion that would require a stack to be implemented into a loop. Is the article wrong or am I misinformed? If the article is correct, I would suggest further citations and notes be added. 68.117.55.155 (talk) 05:11, 25 September 2018 (UTC)

The article is trying to say that it is necessary for this to be done due to finite memory, essentially. The example clarifies it a bit; the recursive implementation on the left in practice requires more memory than the loop implementation on the right, because of the way functions are implemented in most architectures. In practice this means that if you do recursion in C++ or a similar language using the example on the left, you're going to waste a lot of memory, because every time the function is called, space on the stack is reserved for the argument, a base pointer, a return pointer and the function's scope. Does that help? I'm not really sure how to modify the article to explain this better, though, and I don't have a reference on hand that I can add. Namnatulco (talk) 05:27, 25 September 2018 (UTC)