Re: Testing Program Question
On 3 Mar, 11:13, "Leigh Johnston" <le...@i42.co.uk> wrote:
"Michael Doubez" <michael.dou...@free.fr> wrote in message
news:c8a41a6c-18f8-49f9-b43f-05b92fdeaff5@g26g2000yqn.googlegroups.com...
On 3 mar, 00:55, "Leigh Johnston" <le...@i42.co.uk> wrote:
Stack size is not usually deterministic, at least not in
a single threaded program. In practice, stack size
depends on the current setting of ulimits, how much
virtual memory is available, and how much of that is
being used by other processes.
In a single threaded program the maximum stack size is
usually a linker setting.
Under Linux at least, the maximum stack size can be set.
AFAIK it is set by the administrator and can be redefined
per shell. The linker may requires a specific amount of
stack but I don't see how it could control the maximum size.
Stack size *is* *usually* deterministic.
I don't known about that but it make sense to allow the
creation of a process with a stack size smaller than the
default in case of starvation (the OS can make the bet you
won't use it).
By deterministic I mean if you run the same program with the
same inputs its stack usage *should* be the same each time and
a debugger should help you determine what the actual stack
usage is at any point in the program. Given this information
you can determine at what level to set a hard limit for your
recursive function allowing for a graceful abort and/or
continue instead of a stack fault (program termination /
"crash").
That still fails to address the problem: knowing the actual
stack usage at some particular point for some particular set of
data isn't a problem, but it doesn't help us. The problem is to
detect the stack overflow before it happens, which means that
you need to know the maximum amount of stack you can safely use.
And that amount varies in time, in an unpredictable way (at
least under Solaris and Linux---the two systems where I've had
to address the issue concretely).
--
James Kanze