Thread: Heap vs. Stack vs. Data vs. BSS etc.

  1. #1
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300

    Exclamation Heap vs. Stack vs. Data vs. BSS etc.

    Fordy closed a thread on me before I could edit a post that contains some "kind of inaccurate" information:

    Stack buffer overflow - how does it work?

    What I refer to there as the heap is not the heap, it's something else, either the "data" or "code" segment of the executable. Qv.

    Understanding Memory
    Data segment - Wikipedia, the free encyclopedia

    Of course, if anyone in the know wants to get enlightening in this regard, that'd be cool.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  2. #2
    Registered User
    Join Date
    Nov 2010
    Location
    Long Beach, CA
    Posts
    5,909
    I don't know about Windows, but as far as *nix systems go, here's the general breakdown. The code, data, BSS, heap and stack are memory segments, and have permissions just like files do: readable, writable and executable.

    • Code: Where instructions are placed. These memory segments are marked readable and executable.
    • Data: This is where initialized global and static local variables go. The data segment can actually be multiple segments, some of which are read-only, and some of which are readable and writable. The read only sections are usually for things like string literals, and possibly for constant variables.
    • BSS: This stands for "Block Started by Symbol". Basically, this is for uninitialized globals and static locals. They're initialized to 0 (you don't care about their initial value because they're uninitialized). But it's silly to have an array of 100 int's specified in the file as 100 4-byte zeros. So to save space, the array would be stored as something equivalent to "array 400". That tells the loader that it should expand array to be 400 bytes, and it sets it all to zero. This segment is readable and writable.
    • Heap: This is the pool of memory uses for dynamic allocation (malloc, et al). It is readable and writable.
    • Stack: This is where function parameters, non-static locals and other function call data is stored (where to go when the function returns (old instruction pointer), plus the "context" of the calling function (the old stack and base pointers)). This is readable and writable.


    It might be worth noting that the code, data and BSS segments are generally fixed at the lower addresses. The heap sits above those, and "grows" upward in addresses as you allocate memory. The stack starts at the highest address and "grows" downward as your functions call more functions which call more functions, etc.

    I hope that clears it up a bit.

  3. #3
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Okay, so what I referred to in that post as "heap" is from the code segment. I found this:

    oozie's blog: [0x03]. Notes on Assembly - Memory from a process' point of view

    And added a line to main:

    Code:
      printf("\n%p <- global func address\n", &print_sorted);
    print_sorted() being one of the functions, of course. Output:

    1.(0x6d8a9104) stack
    2.(0x008b0010) heap
    3.(0x00601030) bss
    4.(0x00400890) const's
    5.(0x0040073e) code

    0x4005e4 <- global func address


    I guess it makes sense to call that the "code" segment.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  4. #4
    Registered User
    Join Date
    Nov 2010
    Location
    Long Beach, CA
    Posts
    5,909
    Note that the above reflects the memory layout in virtual address space. At any time, unbeknownst to you, some or all of those segments may be paged to disk, or located uncontiguously in RAM. Your program doesn't care though.

    Also, this site has a great explanation of how the stack "grows" as you call functions: Intel x86 Function-call Conventions - Assembly View.

    A quick Google search for "linux memory layout" should turn up some decent reads and some visuals of the layout.

    Also, I forgot that memory mapped stuff like shared libraries and IPC shared memory have to go somewhere. A few images that came up when I googled suggest they sit between the stack and heap, and grow downward.

  5. #5
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by anduril462 View Post
    Note that the above reflects the memory layout in virtual address space. At any time, unbeknownst to you, some or all of those segments may be paged to disk, or located uncontiguously in RAM. Your program doesn't care though.
    In fact, I believe (at least on linux) the writable/private parts of the program can end up completely separate from the read-only parts (such as code), because the read-only parts will be shared amongst instances, whereas each process requires its own writable/private regions.


    Also, I forgot that memory mapped stuff like shared libraries and IPC shared memory have to go somewhere. A few images that came up when I googled suggest they sit between the stack and heap, and grow downward.
    The "oozie" blog linked in my last post puts shared libs between the stack and the heap, yeah, but again that is virtually.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  6. #6
    Registered User
    Join Date
    Nov 2010
    Location
    Long Beach, CA
    Posts
    5,909
    Quote Originally Posted by MK27 View Post
    In fact, I believe (at least on linux) the writable/private parts of the program can end up completely separate from the read-only parts (such as code), because the read-only parts will be shared amongst instances, whereas each process requires its own writable/private regions.
    Yep, you're correct.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Should I use the Heap or the Stack?
    By Swerve in forum C++ Programming
    Replies: 2
    Last Post: 10-08-2009, 12:38 PM
  2. Trying to learn more about stack/heap/global data
    By blernblan in forum C Programming
    Replies: 2
    Last Post: 06-04-2009, 03:30 PM
  3. char* ptr="HELLO"; String Literal:Stack/Heap/Data Segment
    By forumuser in forum C Programming
    Replies: 9
    Last Post: 09-20-2007, 04:53 AM
  4. Replies: 7
    Last Post: 07-31-2007, 09:27 AM
  5. Stack or Heap Private Data...?
    By GrNxxDaY in forum C++ Programming
    Replies: 4
    Last Post: 08-09-2002, 05:13 AM