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.

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
", StackAddress);
   printf ("Stack size:    %u bytes
", StackSize);
   printf ("Stack bottom:  %p
", 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.

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.

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.

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.

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.