Mail Archives: djgpp/2001/07/01/04:34:08
On Sat, 30 Jun 2001, Charles Sandmann wrote:
> Low effort fixes - setting bottom of stack uncommitted - this would
> catch recursive programs that didn't jump down too much stack at once
> and skip the uncommitted section.
Yes, this was considered in the past, but was never a high priority
due to low benefits. Experience shows that the absolute majority of
nasty crashes due to stack overflows are due to huge off-stack
allocations, like a monstrous automatic array or a call to alloca with
a very large argument. These won't be caught by unmapping the stack
bottom.
The number of cases I've seen where stack overflow _could_ be
caught--those with very deep recursion--is so small that it could be
considered nonexistent. I myself only had 1 such case in the last 10
years (a naive implementation of flood-fill), and the number of such
problems reported here is so insignificant that I don't remember
whether I've ever seen one.
There used to be a problem with GCC compiling complex code (GCC uses
alloca extensively, or at least used to use it). We enlarged the
run-time stack of DJGPP programs to 512KB in response to that (and I
think the compiler is stub-edited to even larger stack in latest
ports), and those problems were never heard of since then.
Since unmapping parts of the address space really only works with
CWSDPMI and a couple of rarely used hosts, this doesn't seem like an
important issue. However, as usual, motivated volunteers are welcome
to submit patches.
- Raw text -