Is it possible to predict a stack overflow in C on Linux?

Question

There are certain conditions that can cause stack overflows on an x86 Linux system:

• struct my_big_object[HUGE_NUMBER] on the stack. Walking throu

Answer 1

The alloca function is not deprecated. However, it is not in POSIX and it is also machine- and compiler-dependent. The Linux man-page for alloca notes that "for certain applications, its use can improve efficiency compared to the use of malloc, and in certain cases it can also simplify memory deallocation in applications that use longjmp() or siglongjmp(). Otherwise, its use is discouraged."

The manpage also says that "there is no error indication if the stack frame cannot be extended. However, after a failed allocation, the program is likely to receive a SIGSEGV."

The performance of malloc was actually mentioned on the Stackoverflow Podcast #36.

(I know this is not a proper answer to your question, but I thought it might be useful anyway.)

Answer 2

Several compilers, for example Open Watcom C/C++, support stackavail() function that lets you do exactly that

Answer 3

There isn't a nice way I can think of. Maybe it is possible by using getrlimit() (suggested before) and some pointer arithmetic? But first ask yourself if you really want this.

void *closeToBase;

main () {
  int closeToBase;
  stackTop = &closeToBase;
}

int stackHasRoomFor(int bytes) {
  int currentTop;
  return getrlimit(...) - (¤tTop  - closeToBase) > bytes + SomeExtra;
}

Personally, I'd not do this. Allocate big things on the heap, the stack was not meant for it.

Answer 4

The end of the stack area is determined dynamically by the OS. Although you can find the "static" bounds of the stack by looking at the virtual memory areas (VMAs) in a highly OS dependent way (see the stackvma* files in libsigsegv/src/), you will additionally have to consider

• the getrlimit values,
• the per-thread stack size (see pthread_getstacksize)

Answer 5

Even if this isn't a direct answer to your question, I hope you're aware of the existence of valgrind - a wonderful tool for detecting such problems in runtime, on Linux.

Regarding the stack problem, you can attempt allocating objects dynamically from a fixed pool that detects these overflows. With a simple macro-wizardry you can make this run at debug time, with real code running at release time, and thus know (at least for the scenarios you're executing) that you're not taking too much. Here's more info and a link to a sample implementation.

Answer 6

You don't say much about why you want to allocate on the stack, but if it is the stack memory model which is appealing, you could implement stack allocation on the heap as well. Allocate a large chunk of memory at the beginning of the program and keep a stack of pointers to this which would correspond to frames on the regular stack. You just need to remember to pop your private stack pointer when the function returns.