views:

277

answers:

6

I know that stack size is fixed. So we can not store large objects on stack and we shift to dynamic allocations (e.g. malloc). Also, stack gets used when there is nesting of function calls so we avoid recursive functions as well for this reason. Is there any way at runtime to determine how much stack memory is used so far and how much is left ?

Here, I am assuming linux environment (gcc compiler) with x86 architecture.

+2  A: 

Just read %esp, and remember its value goes down. You already know your defaulted max size from the environment, as well as your threads' starting point.

gcc has great assembly support, unlike some flakes out there.

rama-jka toti
what about heap segment? I heard that stack and heap segments grow opposite to each other? Will that affect the effective size of stack? Correct me if I am wrong here.
vinit dhatrak
for your problem you can treat it as orthogonal.. free store or heap is not the stack space, and 'growing opposite' is not a helpful way to think about it. at the point of heap allocation (new-ing your types) you stack size is likely to be briefly/temporarily affected but that's not the problem you're facing..
rama-jka toti
It is not as simple as "they grow opposite to each other". glibc can simply use mmap() to ask for an additional virtual memory area, and the may in theory live anywhere on the virtual memory address space, so malloc() won't necessarily will use space that would be used by the stack.The allocation method used by glibc for malloc() may vary depending on many factors (e.g. it may use sbrk(), or it may use mmap()).
ehabkost
A: 

That's very much depending on your OS and its memory management. On Linux you can use procfs. It's something like /proc/$PID/memory. I'm not on a Linux box right now.

GCC generally adds 16 bits for the registers (to jump back to the function context referred from) to the stack-frame. Normally you can gain more information on how the program exactly is compiled by disassembling it. Or use -S to get the assembly.

wishi
A: 

If your application needs to be sure it can use X MB of memory the usual approach is for the process to alloc it at startup time (and fail to start if it cannot alloc the minimum requirement).

This of course, means the application has to employ its own memory management logic.

diciu
@diciu, I wanted to know about memory on stack not dynamically allocated memory. Stack is allocated by system and its of fix size.
vinit dhatrak
Not it's not of fixed size. See ulimit - it allows you to control the stack size an OS assigns a process.
diciu
A: 

Tcl had a stack check at some time, to avoid crashing due to unlimted recursion or other out of stack issues. Wasn't too portable, e.g. crashed on one of the BSDs..., but you could try to find the code they used.

schlenk
+1  A: 

You can see the state of the stack virtual memory area by looking at /proc/<pid>/smaps. The stack vma grows down automatically when you use more stack spa. You can check how much stack space you are really using by checking how far %esp is from the upper limit of the stack area on smaps (as the stack grows down). Probably the first limit you will hit if you use too much stack space will be the one set by ulimit.

But always remember that these low level details may vary without any notice. Don't expect all Linux kernel versions and all glibc versions to have the same behavior. I would never make my program rely on this information.

ehabkost
Note, I am talking about Linux on x86 only.
ehabkost
+2  A: 

There is a pthread API to determine where the stack lies:

#include <pthread.h>

void PrintStackInfo (void)
   {   pthread_attr_t Attributes;
       void *StackAddress;
       int StackSize;

   // Get the pthread attributes
   memset (&Attributes, 0, sizeof (Attributes));
   pthread_getattr_np (pthread_self(), &Attributes);

   // From the attributes, get the stack info
   pthread_attr_getstack (&Attributes, &StackAddress, &StackSize);

   // Done with the attributes
   pthread_attr_destroy (&Attributes);

   printf ("Stack top:     %p\n", StackAddress);
   printf ("Stack size:    %u bytes\n", StackSize);
   printf ("Stack bottom:  %p\n", StackAddress + StackSize);
   }

On i386, the stack starts at the bottom and grows towards the top.

So you know you have ($ESP - StackAddress) bytes available.

In my system, I have a wrapper around pthread_create(), so each thread starts in my private function. In that function, I find the stack as described above, then find the unused portion, then initialize that memory with a distinctive pattern (or "Patton", as my Somerville, MA-born father-in-law would say).

Then when I want to know how much of the stack has been used, I start at the top and search towards the bottom for the first value that doesn't match my pattern.

Martin Del Vecchio