LinuxQuestions.org
Download your favorite Linux distribution at LQ ISO.
Go Back   LinuxQuestions.org > Forums > Non-*NIX Forums > Programming
User Name
Password
Programming This forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.

Notices

Reply
 
Search this Thread
Old 05-19-2010, 05:29 PM   #1
theKbStockpiler
Member
 
Registered: Sep 2009
Location: Central New York
Distribution: Fedora14,Scientific 6.1?, Mandriva 2010 ;GO MAGEIA!!!Next up Gentoo
Posts: 836

Rep: Reputation: 51
Processes ,the stack and static memory: How can the stack be considered static?


I'm reading a tutorial that says that processes store variable data in the same space as code. It also does not exclude the stack from static memory. How can the stack change and be part of static memory? Is the size of the stack accounted for when it is compiled?

Thanks in advance
Stating that (no offense is intended) is not required for this thread.
The source of confusion is located at:
http://arjay.bc.ca/Modula-2/Text/Ch12/Ch12.4.html

Last edited by theKbStockpiler; 05-19-2010 at 05:30 PM.
 
Click here to see the post LQ members have rated as the most helpful post in this thread.
Old 05-19-2010, 06:09 PM   #2
johnsfine
Guru
 
Registered: Dec 2007
Distribution: Centos
Posts: 5,138

Rep: Reputation: 1127Reputation: 1127Reputation: 1127Reputation: 1127Reputation: 1127Reputation: 1127Reputation: 1127Reputation: 1127Reputation: 1127
Are you confused by just the following section or by something more?
Quote:
observe that what has been said so far about static memory for program variable also applies to procedures in exactly the same way. Just as whenever a program is run static memory is set aside, so also whenever a procedure is entered, memory must be set aside for its parameters and variables. (The code for the procedure has memory within the block of memory for the code of the entire program.) When the procedure is running, the memory it employs for its variables can be regarded as static. Indeed, the relative positions of the memory for each variable with respect to the start of this memory block is all worked out by the compiler ahead of time so that assignments to such variables may be properly coded.
That certainly introduces an important way in which stack data is similar to static data and both are dissimilar to dynamic data.

But you seem to be upset about some greater level of equivalence between stack and static than I've noticed in the page.

Quote:
Is the size of the stack accounted for when it is compiled?
In a single threaded Windows program, the size and location of the stack are in the executable (normally determined at link time). In Linux the size of the first thread's stack is not determined until load time.
 
2 members found this post helpful.
Old 05-19-2010, 06:46 PM   #3
theKbStockpiler
Member
 
Registered: Sep 2009
Location: Central New York
Distribution: Fedora14,Scientific 6.1?, Mandriva 2010 ;GO MAGEIA!!!Next up Gentoo
Posts: 836

Original Poster
Rep: Reputation: 51
I'm more or less more disturbed than upset. There are not that many good synonyms f

Quote:
Originally Posted by johnsfine View Post
Are you confused by just the following section or by something more?


That certainly introduces an important way in which stack data is similar to static data and both are dissimilar to dynamic data.

But you seem to be upset about some greater level of equivalence between stack and static than I've noticed in the page.



In a single threaded Windows program, the size and location of the stack are in the executable (normally determined at link time). In Linux the size of the first thread's stack is not determined until load time.
I'm pretty sure you understand.

I think what you are saying in the windows example is that the size and address are included in the executive but data is located some where else? Its that correct? Static memory would then change but it's size and location is stated in the code?
 
Old 05-19-2010, 07:31 PM   #4
Sergei Steshenko
Senior Member
 
Registered: May 2005
Posts: 4,481

Rep: Reputation: 453Reputation: 453Reputation: 453Reputation: 453Reputation: 453
Quote:
Originally Posted by theKbStockpiler View Post
I'm reading a tutorial that says that processes store variable data in the same space as code. It also does not exclude the stack from static memory. How can the stack change and be part of static memory? Is the size of the stack accounted for when it is compiled?
...
What is the problem with stack being static or, rather, what are your definitions of static and dynamic in this context ?
 
Old 05-19-2010, 07:32 PM   #5
paulsm4
Guru
 
Registered: Mar 2004
Distribution: SusE 8.2
Posts: 5,863
Blog Entries: 1

Rep: Reputation: Disabled
Remember - the article is about Modula 2. So the some of the details may or may not be applicable to "stacks" in general!

But the *main* point I believe he's trying to make in the article has to do with the concept of "activation records":

Quote:
The memory assigned to a procedure for its parameters and variables when it is invoked is called an activation record for the procedure.
...

The area of memory into which procedure activation records are dynamically and automatically placed is called the stack.
This is in contrast to "Dynamic variables":
Quote:
Dynamic variables are those that can have the space allocated to them as needed at some point during the execution of a program or procedure and that can also be disposed of and have their space given back to the system by the program.
...
The region of memory above the stack and in which program-controlled dynamic allocation and deallocation of memory can take place is called the heap.
'Hope that helps .. PSM
 
Old 05-19-2010, 09:52 PM   #6
theKbStockpiler
Member
 
Registered: Sep 2009
Location: Central New York
Distribution: Fedora14,Scientific 6.1?, Mandriva 2010 ;GO MAGEIA!!!Next up Gentoo
Posts: 836

Original Poster
Rep: Reputation: 51
I think this thread is answered. I wish they were all this easy

Quote:
Originally Posted by Sergei Steshenko View Post
What is the problem with stack being static or, rather, what are your definitions of static and dynamic in this context ?

johnsfine I believe deciphered the "The code for the procedure has memory within the block of memory for the code of the entire program." The code holds the size and relative address but not the actual data.

After I read the tutorial another six times I discovers that;

In addition It actually looks like the author is trying to convey 3 types of memory.

1 Static

2,Automatic Dynamics

3.Dynamic

It's my mistake that they are just describing a black or white Static or Dynamic memory types. They are not.

I'm reading about program memories to fill in some blank spots of my general understanding of programming. It's seams common for an author to explain concepts with other concepts that are outside the immediate scope of information. Every time I read a book on C I get side tracked. Thanks for asking

Last edited by theKbStockpiler; 05-19-2010 at 09:54 PM. Reason: I'm literacy challenged
 
Old 05-19-2010, 10:06 PM   #7
Sergei Steshenko
Senior Member
 
Registered: May 2005
Posts: 4,481

Rep: Reputation: 453Reputation: 453Reputation: 453Reputation: 453Reputation: 453
Quote:
Originally Posted by theKbStockpiler View Post
johnsfine I believe deciphered the "The code for the procedure has memory within the block of memory for the code of the entire program." The code holds the size and relative address but not the actual data.

After I read the tutorial another six times I discovers that;

In addition It actually looks like the author is trying to convey 3 types of memory.

1 Static

2,Automatic Dynamics

3.Dynamic

It's my mistake that they are just describing a black or white Static or Dynamic memory types. They are not.

I'm reading about program memories to fill in some blank spots of my general understanding of programming. It's seams common for an author to explain concepts with other concepts that are outside the immediate scope of information. Every time I read a book on C I get side tracked. Thanks for asking
If we are talking about "C" and its dynamic (auto) variables, they are dynamic in a sense their address is not known at compilation and even link time. I.e. their address is known at the moment a function containing them is called. And the called function may be called after (many) other functions are called, and this (how many other functions have been called before) can change during the execution.

So, the dynamic/auto variables have no fixed address, and in this sense their address is dynamic.

Now, it happens so that the piece of memory where these dynamic/auto variables reside is called stack. But by itself this piece of memory may quite be static in a sense its start address and size is known beforehand.

For that matter, the address of the area where global/static variables reside may be dynamic - it depends on the way the OS deals with it and how addressing in general is implemented in a given CPU. I.e. a CPU may have so called base registers and addressing may be implemented as relative to those base registers.

Furthermore, in, say, x86 it is all even further moot because there are segment registers to add to the confusion.
 
1 members found this post helpful.
Old 05-20-2010, 12:26 AM   #8
wje_lq
Member
 
Registered: Sep 2007
Location: Mariposa
Distribution: Debian lenny, Slackware 12
Posts: 809

Rep: Reputation: 178Reputation: 178
the size of the stack in Linux on x86

The actual size of the stack usually doesn't matter, because the stack grows "automatically" (that is, the operating system responds by making the stack grow and restarting the instruction which caused the discovery that the stack needed to grow), up to a certain limit. What is that limit?

The limit is determined later than compile time, and earlier than the time that the program is loaded. The limit is determined by the shell that runs the program. You can ask the shell what that limit is, and change that limit, with the ulimit command. And your C program can examine and change that limit while it's running with getrlimit() and setrlimit().

To illustrate, here is a shell script which compiles a C program and runs it. The program causes the stack segment to grow to its limit through infinite recursion. Each time the actual size of the segment changes, the recursion count and the appropriate line of /proc/self/maps is listed.

The shell script actually runs the program twice. The second time, the program doubles the stack size limit at the beginning.

The output is quite lengthy, so you might want to redirect it to a file and examine that file with less.

Before running this, you might want to
Code:
less /proc/self/maps
Anyway, here's the shell script.
Code:
rm -f 1; cat <<EOD >1.c; gcc -Wall -Werror 1.c -o 1; ./1; ./1 x
/*--------------------------------------------------------------------------*/
#include <sys/resource.h>
#include <sys/time.h>
#include <sys/types.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
/*--------------------------------------------------------------------------*/
#define MAP_PATH "/proc/self/maps"
char  old_line[4096];
/*--------------------------------------------------------------------------*/
void measure(int count_dracula)
{
  char  new_line[4096];

  FILE *map_phyle;

  map_phyle=fopen(MAP_PATH,"r");

  if(map_phyle==NULL)
  {
    perror("opening maps file");

    exit(1);
  }

  while(fgets(new_line,sizeof(new_line),map_phyle))
  {
    if(strstr(new_line,"[stack]"))
    {
      break;   /* <--------- */
    }
  }

  fclose(map_phyle);

  if(strcmp(old_line,new_line))
  {
    strcpy(old_line,new_line);

    printf("%d %s",count_dracula,new_line);

    fflush(stdout);
  }

} /* measure() */
/*--------------------------------------------------------------------------*/
void crank_her_up(int depth)
{
  measure(depth);
  depth++;
  crank_her_up(depth);

} /* crank_her_up() */
/*--------------------------------------------------------------------------*/
int main(int argc,
         char **argv
        )
{
  struct rlimit our_limit;

  if(getrlimit(RLIMIT_STACK,&our_limit))
  {
    perror("getrlimit");

    exit(1);
  }
  if(argc>1)
  {
    our_limit.rlim_cur*=2;
    if(setrlimit(RLIMIT_STACK,&our_limit))
    {
      perror("getrlimit");

      exit(1);
    }
  }
  printf("stack limit is %ld soft, %ld hard\n",our_limit.rlim_cur,our_limit.rlim_max);
  crank_her_up(0);
  return 0;

} /* main() */
EOD
 
1 members found this post helpful.
Old 05-20-2010, 10:01 AM   #9
johnsfine
Guru
 
Registered: Dec 2007
Distribution: Centos
Posts: 5,138

Rep: Reputation: 1127Reputation: 1127Reputation: 1127Reputation: 1127Reputation: 1127Reputation: 1127Reputation: 1127Reputation: 1127Reputation: 1127
Quote:
Originally Posted by wje_lq View Post
The actual size of the stack usually doesn't matter, because the stack grows "automatically" (that is, the operating system responds by making the stack grow and restarting the instruction which caused the discovery that the stack needed to grow), up to a certain limit.
That description differs only in terminology, not meaning, from what I said.

There are many situations in which the kernel delays (and usually avoids) allocating physical memory that appears to the program to have been allocated. When discussing behavior as seen from inside the program, one normally ignores those optimizations and pretends the memory is there.

For example, if your C program allocates a giant static uninitialized array, the loader will seem to fill that space with zeroes. Actually it won't. That memory won't even exist when the loader is done. Each page of that memory will become zero filled the first time it is read and/or it will be allocated and zero filled the first time it is written. But if a C programmer wants to know the initial contents of a giant uninitialized static array, the answer is just "zero filled", not the above complicated way of saying zero filled if necessary later.

From the viewpoint inside a process, the size allocated to the first thread's stack is the whole amount of virtual memory reserved for it, regardless of how much of that happens to be backed by any physical storage at the moment.
 
1 members found this post helpful.
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
single 8K process stack vs 4K process stack and a seperate 4K interrupt stack charvak Linux - Kernel 1 03-17-2010 07:58 PM
Call Stack Memory Management pseudosig Linux - Kernel 6 10-03-2008 01:03 PM
Difference b/t Kernel stack and User stack hazzyb Linux - Software 2 09-29-2008 08:40 PM
Memory for local variable in C on stack shivaligupta Programming 10 01-20-2007 02:22 AM
allocation problem [static stack storage] kranti Programming 1 10-18-2005 10:10 AM


All times are GMT -5. The time now is 12:42 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration