Required stack size

[mkovac]

Hi all,

I would like to know how much stack memory is used when program is
running. Can this be achived in some portable way? At least I would
like to know this on Linux. I already managed to get this with the help
of gcc instrument functions to check the value of stack pointer when
program is entering in functions.

link:
http://groups-beta.google.com/group/comp.os.linux.development.apps/
browse_frm/thread/da68b2ed4493d7b6/a9e5586726639754?q=get+stack+
usage+of+process&_done=%2Fgroups%3Fhl%3Den%26q%3Dget+stack+usage+
of+process%26qt_s%3DSearch+Groups%26&_doneTitle=Back+to+Search&&d#a9e5586726639754

Thanks for any advice.

Miha

 

[Flash Gordon]

Hi all,

I would like to know how much stack memory is used when program is
running. Can this be achived in some portable way? At least I would
like to know this on Linux. I already managed to get this with the help
of gcc instrument functions to check the value of stack pointer when
program is entering in functions.

link:
http://groups-beta.google.com/group..._doneTitle=Back+to+Search&&d#a9e5586726639754

This can't be done in a portable way. It might be possible with
implementation specific extensions, but any such solution would be off
topic for comp.lang.c

I've set follow-ups to be just comp.os.linux.development.apps so that
you can continue discussing the Linux specific methods where they might
be appropriate.

I've also glued together the URL you gave since google was kind enough
to split it across multiple lines for you thus breaking it.

 

[Kasper Dupont]

Hi all,

I would like to know how much stack memory is used when program is
running. Can this be achived in some portable way? At least I would
like to know this on Linux. I already managed to get this with the help
of gcc instrument functions to check the value of stack pointer when
program is entering in functions.

This is the most portable I can come up with:

char *approx_stack_pointer()
{
char dummy;
return &dummy;
}

Just call this from your main function and when the
stack is highest, and substract the results. Take
the numerical value of the result (as you don't know
if the stack is growing up or down).

If you just need it to run on Linux you may parse
/proc/self/maps

 

[Thomas Matthews]

Hi all,

I would like to know how much stack memory is used when program is
running. Can this be achived in some portable way? At least I would
like to know this on Linux. I already managed to get this with the help
of gcc instrument functions to check the value of stack pointer when
program is entering in functions.
Thanks for any advice.

Miha

Assuming that an implementation is using a stack,
a rough estimate is to take the maximum of:
1. The number of function calls for the deepest
execution path.
2. The function with the most or largest amount
of non-static local variable space.
This is a rough estimate since there is no method
to find the maximum stack space using the standard
C language (simply because the language doesn't
require implementations to have stacks).

--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.comeaucomputing.com/learn/faq/
Other sites:
http://www.josuttis.com -- C++ STL Library book
http://www.sgi.com/tech/stl -- Standard Template Library

 

[Ed Skinner]

This is the most portable I can come up with:

char *approx_stack_pointer()
{
char dummy;
return &dummy;
}
}
Just call this from your main function and when the stack is highest, and
substract the results. Take the numerical value of the result (as you
don't know if the stack is growing up or down).

If you just need it to run on Linux you may parse /proc/self/maps

Very nice. An elegant solution. Thank you!

 

[Keith Thompson]

This is the most portable I can come up with:

char *approx_stack_pointer()
{
char dummy;
return &dummy;
}

Just call this from your main function and when the
stack is highest, and substract the results. Take
the numerical value of the result (as you don't know
if the stack is growing up or down).

(I think you mean absolute value rather than numerical value.)

You should be aware that the C language doesn't guarantee that this is
going to work. Comparing or subtracting pointers that don't point
into the same object (or just past the end of it) invokes undefined
behavior.

Having said that, it's likely to work on many systems; just don't
expect it to be *completely* portable.

 

[E. Robert Tisdale]

You should be aware that
the C language doesn't guarantee that this is going to work.

Can you show us one example
of an ANSI/ISO C standard compliant compiler
where this doesn't work?

Comparing or subtracting pointers
that don't point into the same object
(or just past the end of it) invokes undefined behavior.

Is this remark relevant here?
The ANSI/ISO C standards don't even specify a stack
so there is no point in even mentioning the standards.

 

[Kasper Dupont]

(I think you mean absolute value rather than numerical value.)

My bad. (English isn't my native language).

You should be aware that the C language doesn't guarantee that this is
going to work.

Of course not.

Comparing or subtracting pointers that don't point
into the same object (or just past the end of it) invokes undefined
behavior.

If the stack is implemented using a stack pointer like we
are used to, then I'd expect it to work. Otherwise not.

Having said that, it's likely to work on many systems; just don't
expect it to be *completely* portable.

I never said it was perfect, just that it was the most
portable I could come up with. Do you have a more
portable solution?

 

[Keith Thompson]

Keith Thompson wrote: [...]

Having said that, it's likely to work on many systems; just don't
expect it to be *completely* portable.

I never said it was perfect, just that it was the most
portable I could come up with. Do you have a more
portable solution?

No; I don't believe there is one. (And I didn't mean to imply that
your solution is a bad one, only that it's not 100% portable.)

 

[Keith Thompson]

Can you show us one example
of an ANSI/ISO C standard compliant compiler
where this doesn't work?
No.


Is this remark relevant here?
The ANSI/ISO C standards don't even specify a stack
so there is no point in even mentioning the standards.

Of course it's relevant here. This is comp.lang.c, where we discuss
the C programming language, which is defined by the ANSI/ISO C
standards. But you knew that.

Any C implementation must implement a "stack", in the sense that local
data for function invocations is created and destroyed in a
first-in-last-out fashion. There could be implementations in which
this "stack" isn't allocated sequentially in memory (for example, each
stack frame might be allocated on a heap). Under such an
implementation, it could be meaningful to ask how much stack size has
been consumed, but the proposed solution won't work.

My point is not that I know of any real-world implementations for
which this is the case. My point is simply that such implementations
would not violate the standard, and the proposed solution is therefore
not absolutely portable.

The proposed solution was:

char *approx_stack_pointer()
{
char dummy;
return &dummy;
}

The function returns the address of a local variable (and one that's
never used); attempting to use that address after the function returns
invokes undefined behavior, since it becomes indeterminate. (I had
forgotten about that point.)

Even assuming a traditional linear hardware stack, an optimizing
compiler could replace the function with:

char *approx_stack_pointer()
{
return 0;
}

If you disagree, please cite the section of the standard that
disallows it.

(I don't know or care whether any actual compiler does this; someone
could release such a compiler tomorrow.)

(A quick experiment shows that gcc doesn't perform this optimization,
but it does warn about returning the address of a local variable.)

Again, it's not a bad solution. It's not guaranteed portable, but no
solution is. You just need to be aware of the possible pitfalls.

 

[E. Robert Tisdale]

Of course it's relevant here. This is comp.lang.c, where we discuss
the C programming language, which is defined by the ANSI/ISO C
standards. But you knew that.

Any C implementation must implement a "stack", in the sense that local
data for function invocations is created and destroyed in a
first-in-last-out fashion. There could be implementations in which
this "stack" isn't allocated sequentially in memory (for example, each
stack frame might be allocated on a heap). Under such an
implementation, it could be meaningful to ask how much stack size has
been consumed, but the proposed solution won't work.

My point is not that I know of any real-world implementations for
which this is the case. My point is simply that such implementations
would not violate the standard, and the proposed solution is therefore
not absolutely portable.

The proposed solution was:

char *approx_stack_pointer()
{
char dummy;
return &dummy;
}

The function returns the address of a local variable (and one that's
never used); attempting to use that address after the function returns
invokes undefined behavior, since it becomes indeterminate. (I had
forgotten about that point.)

Even assuming a traditional linear hardware stack, an optimizing
compiler could replace the function with:

char *approx_stack_pointer()
{
return 0;
}

If you disagree, please cite the section of the standard that
disallows it.

(I don't know or care whether any actual compiler does this; someone
could release such a compiler tomorrow.)

(A quick experiment shows that gcc doesn't perform this optimization,
but it does warn about returning the address of a local variable.)

Again, it's not a bad solution. It's not guaranteed portable, but no
solution is. You just need to be aware of the possible pitfalls.

No.
The program stack is off-topic in the comp.lang.c newsgroup.
It would have been better if you had simply ignored it
but you chose instead to respond.
The question was about portability and *not* compliance.
Your remarks go to hypothetical situations --
non-existent implementations that the standards allow --
yet you present them as if they were actual implementations
that would probably cause problems for programmers.

The ANSI/ISO C standards specify very little about implementations.
Your comments about actual implementations
should be based upon knowledge of actual implementation
and *not* what the standards fail to say about them.

 

[Chris Williams]

Any C implementation must implement a "stack", in the sense that local
data for function invocations is created and destroyed in a
first-in-last-out fashion. There could be implementations in which
this "stack" isn't allocated sequentially in memory (for example, each
stack frame might be allocated on a heap). Under such an
implementation, it could be meaningful to ask how much stack size has
been consumed, but the proposed solution won't work.

I don't have a copy of the C standard, but looking at the following it
does not appear that a stack is required:

http://www.vmunix.com/~gabor/c/draft.html

To the OP, though, I do think that one can portably determine how much
room is required for all local variables up at any given point if you
add in enough code. Simply whether that data is held in memory, on
disk, or only in registers would still be unknown--you would just know
that it does exist somewhere and is requiring _at least_ x amount of
bytes.

unsigned int totalSpace;

int foo(int bar, int baz) {
int bop;
int beep;

unsigned int localSpace = sizeof(bar) + sizeof(baz) + sizeof(bop) +
sizeof(beep) + sizeof(localSpace);
totalSpace += localSpace;

...

totalSpace -= localSpace;
return bop;
}

-Chris

 

[Lawrence Kirby]

I don't have a copy of the C standard, but looking at the following it
does not appear that a stack is required:

It doesn't require anything in the form of a "processor stack" e.g.
something with a "stack pointer". However a C implementation is required
to support recursive function calls which implies datastructures for
automatic variables with stack-like properties. An implementation doesn't
have to use that in all cases. E.g. if it determines that a function can't
be called recursively (e.g. the function makes no function calls itself)
then it could allocate workspace for that function statically. Well
perhaps, it would probably also have to determine that the function can't
be called from an asynchronous signal handler.

Lawrence

 

[Flash Gordon]

I don't have a copy of the C standard, but looking at the following it
does not appear that a stack is required:

http://www.vmunix.com/~gabor/c/draft.html

True, no stack is required.

To the OP, though, I do think that one can portably determine how much
room is required for all local variables up at any given point if you
add in enough code. Simply whether that data is held in memory, on
disk, or only in registers would still be unknown--you would just know
that it does exist somewhere and is requiring _at least_ x amount of
bytes.

unsigned int totalSpace;

int foo(int bar, int baz) {
int bop;
int beep;

unsigned int localSpace = sizeof(bar) + sizeof(baz) + sizeof(bop) +
sizeof(beep) + sizeof(localSpace);
totalSpace += localSpace;

This does not allow for possible padding. For instance, there are
compilers which insert guard values on the stack so that they can
attempt to detect some buffer overruns. So the memory usage may be
greater than you think. Also you are failing to allow for registers and
the program counter being pushed on to the stack if there is one.