Where does malloc() allocate to?

This is a discussion on Where does malloc() allocate to? within the C Programming forums, part of the General Programming Boards category; I'm debugging a program that I wrote and I notice several things: variables and pointers within a current function are ...

  1. #1
    Registered User
    Join Date
    Dec 2007
    Posts
    51

    Where does malloc() allocate to?

    I'm debugging a program that I wrote and I notice several things:

    variables and pointers within a current function are stored on stack frames located at: 0xbf******

    malloc() allocates my pointers to: 0x80******

    Does it always always use bf and 80? What do we call 0x80 (I know we call 0xbf the stack)

  2. #2
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,687
    That's just how your particular implementation works.

    Malloc memory comes from the heap.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

  3. #3
    Frequently Quite Prolix dwks's Avatar
    Join Date
    Apr 2005
    Location
    Canada
    Posts
    8,048
    Those addresses would probably be different if you ran the program on a different computer, or ran a few other programs and then ran yours. (To take up more memory.)
    dwk

    Seek and ye shall find. quaere et invenies.

    "Simplicity does not precede complexity, but follows it." -- Alan Perlis
    "Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
    "The only real mistake is the one from which we learn nothing." -- John Powell


    Other boards: DaniWeb, TPS
    Unofficial Wiki FAQ: cpwiki.sf.net

    My website: http://dwks.theprogrammingsite.com/
    Projects: codeform, xuni, atlantis, nort, etc.

  4. #4
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    It looks to me like the high numbers are in the stack and the low ones on the heap. What do CPU register addresses look like and will I ever see them?
    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

  5. #5
    Registered User
    Join Date
    Apr 2006
    Posts
    2,053
    Quote Originally Posted by MK27 View Post
    What do CPU register addresses look like and will I ever see them?
    Registers are not mapped to memory addresses. They are identified in a different way.
    It is too clear and so it is hard to see.
    A dunce once searched for fire with a lighted lantern.
    Had he known what fire was,
    He could have cooked his rice much sooner.

  6. #6
    Registered User
    Join Date
    Dec 2007
    Posts
    51
    If thats the case, then are constants (#DEFINE) stored on the stack or heap?

  7. #7
    The larch
    Join Date
    May 2006
    Posts
    3,573
    #define's are replaced in the source code before compiling.
    I might be wrong.

    Thank you, anon. You sure know how to recognize different types of trees from quite a long way away.
    Quoted more than 1000 times (I hope).

  8. #8
    Registered User
    Join Date
    Dec 2007
    Posts
    51
    Quote Originally Posted by anon View Post
    #define's are replaced in the source code before compiling.
    Well actually they are stored in .bss when compiled and linked. What part of the memory segment are they located at when the program is executed? Stack or heap?

  9. #9
    and the Hat of Guessing tabstop's Avatar
    Join Date
    Nov 2007
    Posts
    14,185
    Quote Originally Posted by someprogr View Post
    Well actually they are stored in .bss when compiled and linked. What part of the memory segment are they located at when the program is executed? Stack or heap?
    Program data.

  10. #10
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by someprogr View Post
    Well actually they are stored in .bss when compiled and linked. What part of the memory segment are they located at when the program is executed? Stack or heap?
    #defines disappear before the proper compiler sees the code - this is the job of the C preprocessor .

    .bss is part of data in most systems, but sometimes it is considered it's own section (but in most parts equivalent to .data).

    Based on the numbers you quote for the stack addresses and heap addresses, I guess that you are using Linux on x86 with a 32-bit build of Linux (and the OS is set up for 1GB of Kernel space, rather than the settings used in Linux kernels in ancient times, wher the user-space was 1GB and kernel space had 3GB to play with). In this setup, the stack is located at the highest address that is available to the user-mode code, 0xC0000000, and the stack grows towards zero.

    The heap, as it happens, starts at a low address, and grows towards the stack. This is a fairly common scenario, but it by no means HAS to be this way. The OS and software that loads/builds applications can do these things just about any way they like. There are restrictions with regards to the processor architectue (e.g. in x86, it would be nigh on impossible to create a system where the stack grows towards higher addresses - because you would have to replace all CALL and RET instructins with a "store the address we want to return to on the reverse-growing stack" and use a "restore from stack then jump" - it could be done, but it's hard work [and you almost certainly couldn't do that for the OS kernel].

    Note that stack, heap, data, bss and code are all the same type of memory chips. Code is slightly different in the sense that the memory is tagged in the MMU [1] as executable and read-only, whilst data is not executable [2]. Other than that, it's just a suitable way of collecting parts of application that is similar together in one lump, rather than having a bit of code, a bit of data, a bit of this, and bit of that all over the place in some "as needed" arrangment.

    [1] MMU is what translates your applications virtual address into a physical location in memory. As you may have seen, all applications appear to use the same address in memory, even if they are executing at the same time. That obviously wouldn't work [unless we shuffle A LOT of code and data around on each task-switch, that is], so the CPU itself has a MMU (Memory Management Unit) that "maps" the addresses that the application sees onto the physical addres of the memory.

    [2] Some older processors may not be able to distinguish between executable and non-executable memory - but those that do, will mark Code as executable.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. malloc error can't allocate region on mac os X
    By simone.marras in forum C Programming
    Replies: 6
    Last Post: 02-28-2009, 04:59 AM
  2. Replies: 3
    Last Post: 10-19-2008, 03:35 PM
  3. Malloc and calloc problem!!
    By xxhimanshu in forum C Programming
    Replies: 19
    Last Post: 08-10-2005, 05:37 AM
  4. Problem with malloc() and sorting words from text file
    By goron350 in forum C Programming
    Replies: 11
    Last Post: 11-30-2004, 09:01 AM
  5. How do I use malloc to allocate memory for a linked list?
    By Unregistered in forum C Programming
    Replies: 2
    Last Post: 09-14-2001, 01:02 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21