Why are stack overflows still a problem?

Question

This question is mystifying me for years and considering this site\'s name, this is the place to ask.

Why do we, programmers, still have this StackOverflow

Answer 1

I've never personally encountered a stack overflow that wasn't caused by infinite recursion. In these cases, a dynamic stack size wouldn't help, it would just take a little longer to run out of memory.

Answer 2

I am going to summarize the arguments in the answers so far because I find no answer covering this topic good enough.

Static stack investigation

Motivation

Not everyone needs it.

• Most algorithms do not use deep recursion or a lot of threads, thus not a lot of people need dynamic stacks.
• Dynamic stack would make an infinite-recursion stack overflow, which is an easy mistake to make, harder to diagnose. (memory overflow, while being as deadly as a stack overflow to the current process, is hazardous for other processess as well)
• Every recursive algorithm can be emulated with a similar iterative one.

Implementation difficulties

Dynamic stack implementation turns out to be not as straightforward as it seems.

• Stack resizing alone is not enough unless you have unlimited address space. You will sometimes need to relocate the stack as well.
• Stack relocation would require updates for all the pointers to the data structures allocated on the stack. While it is straightforward (at least in managed languages) for the data in memory, there is no easy way to do the same for data in the CPU registers of the thread.
• Some CPUs (microcontrollers in particular) implement the stack directly on hardware, separate from the main memory.

Existing implementations

There are some languages or runtime libraries that already have the dynamic stack feature or something similar to it.

• Some runtime libraries (which?) do not pre-commit the entire block of memory allocated for stack. This can alleviate the problem, expecially for 64-bit systems, but not completely eliminate it.
• Ira Baxter told us about PARLANSE, a language specifically designed for dealing with complex data structures with high degree of parallelism. It uses small heap-allocated "grains" of work instead of stack.
• fuzzy lolipop told us that "Properly written Erlang doesn't have stackoverflows!"
• Google Go programming language is said to have a dynamic stack. (a link would be nice)

I would like to see more examples here.

I hope I didn't forget any important pieces of information on this subject. Making this a community wiki so that anyone can add new information.

Answer 3

Why in every major language does the thread stack memory have to be statically allocated on thread creation?

Stack size and allocation is not necessarily related to the language you are using. It is more a question of processor and architecture.

Stack Segments are limited to 4GB on current Intel processors.

This following link is a good read, that may give you some of the answers you seek.

http://www.intel.com/Assets/PDF/manual/253665.pdf - Chapter 6.2

Answer 4

Old languages implementations have static stack size, thus most new popular languages (that just copied old languages, and broke/fixed whatever they felt like) have the same issue.

There is no logical reason to have a static stack size unless you are in a formal methods setting. Why introduce faults where the code is correct? Erlang for example doesn't do this, because it handles faults, like any sane partial programming language should do.

Answer 5

I think we will see this restriction removed in a few years.

There is simply no fundamental technical reason for fixed size stackes. They exist for historical reasons and because the programmers of compilers and VM's are lazy and don't optimize if it is good enough right now.

But GO the google language already starts with a different approach. It allocates the stack in small 4K pieces. There are also many "stackless" programming language extensions like stackless python etc who are doing the same.

The reason for this is quite simple, the more threads you have the more address space is wasted. For programs which are slower with 64bit pointers it is a serious problem. You can't really have more then hundert threads in practice. This is not good if you write a server which might want to server 60000 clients with a thread for each one (wait for the 100 core/cpu systems in the near future).

On 64bit systems it's not so serious but it still requires more resources. For example TLB entries for pages are extremely serious for good performance. If you can satisfy 4000 normal thread stackes with one single TLB entry (given a page size of 16MB and 4KB active stack space) you can see the difference. Don't waste 1020KB just for stack that you almost never use.

Small grained multithreading will be a very very important technique in the future.