I'm using MinGW with GCC 3.4.5 (mingw-special vista r3).
My C application uses a lot of stack so I was wondering is there any way I can tell programatically how much stack is remaining so I can cleanly handle the situation if I find that I'm about to run out.
If not what other ways would you work around the problem of potentially running out of stack space?
I've no idea what size of stack I'll start with so would need to identify that programatically also.
check if your compiler supports stackavail()
maybe this will help for Windows platform only:
in the PE header (IMAGE_NT_HEADERS) of your exe there are some records such as:
There is a simple way to obtain these values: using GetModuleHandle(NULL) will give you the imagebase (handle) of your module, address where you'll find a IMAGE_DOS_HEADER structure which will help you to find the IMAGE_NT_HEADERS structure (imagebase+IMAGE_DOS_HEADER.e_lfanew) -> IMAGE_NT_HEADERS, and there you'll find those fields: SizeOfStackReserve and SizeOfStackCommit.
The maximum amount of space that the OS will allocate for your stack is SizeOfStackReserve.
If you consider trying this, let me know and I will assist you. There is a way to obtain the size of stack used in a certain point.
This is a problem I have given up on. With a lot of hacking and (mostly) praying, you can get a solution that works at a given time on a given machine. But in general there seems to be no decent way to do this.
You will have to obtain the stack position and size from outside your program (on Linux you might get it from
/proc/<pid>/maps
). In your program you must somehow test where you are at the stack. Using local variables is possible, but there is no real guarantee that they are actually on the stack. You can also try to get the value from the stack pointer register with some assembly.So now you have the location of the stack, its size and the current position and you assume you know in which direction the stack grows. When are you going in stack-overflow mode? You better not do it close to the end because your estimation (i.e. address of local variable or value from stack pointer) is probably a bit too optimistic; it's not uncommon to address memory beyond the stack pointer. Also, you have no clue about how much room on the stack any given function (and the functions it calls) need. So you'll have to leave quite some room at the end.
I can only advice you not do get into this mess and try to avoid very deep recursion. You might also want to increase your stack size; on Windows you have to compile this into the executable, I believe.