0

I am working an OS program and I am trying to figure out how malloc works pertaining to the stack. When a user calls malloc, is the pointer returned from malloc at the top of the stack and after the given space or at the bottom of the given space?

If I am loading variables into this new space using assembly code, and it isn't enough to fill the whole space, should the variables be pushed in at the beginning of the freed space, or pushed to the point where the last variable would take up the last amount of free space given from malloc?

Thanks.

Lucas
  • 1,577
  • 6
  • 18
  • 25

4 Answers4

3

The whole point of malloc is to not allocate from the stack, but from the heap. If you want to allocate from the stack, you'd use alloca.

If you allocate on the stack and leave your current stack frame (that is, you return from the function) then the previously stack-allocated stuff might (in most situations: will) be overwritten by a different function call later on. So this obviously is not the place for "long-term" storage. For data that need to live longer than a function call, you need to allocate from the heap. That's what malloc does.

How malloc is doing its work depends on the OS features available and the implementation. See the question: How do malloc() and free() work?.

Community
  • 1
  • 1
DarkDust
  • 90,870
  • 19
  • 190
  • 224
  • So if I wanted to create another thread using malloc, I would be pushing the function and variables into the heap? Not the stack? Is it better to use alloca for this instead? – Lucas Feb 02 '12 at 23:02
  • You don't create another thread with malloc. You're confusing a few things here, it seems (or I don't understand you ;-). You create a new thread by OS dependent methods, for example, on UNIX you're usually using `pthread_create`. If you want to store data that the new thread needs to use, you need to allocate on the heap using `malloc` and pass it to the new thread either via a global variable (bad; think "fixed memory location") or by passing arguments to the thread-creation function. (continued in next comment) – DarkDust Feb 02 '12 at 23:11
  • If you want to write your own OS, you need to get familiar with how this works on a "normal" OS first. Or grab a book, like *Operating Systems: Design and Implementation* from Andrew S. Tanenbaum. You will also need to get familiar with how your architecture (like x86) is aiding you to do context switching and thread/process handling. There are several books that talk about it. It's not something that can be answered in a useful way on StackOverflow, IMHO, since the topic is too complex. – DarkDust Feb 02 '12 at 23:14
  • Thank you, that gives me a better understanding. Last question if you don't mind, does the heap follow the same structure as a stack in that it is upside down (where negative is at the top)? Because essentially what I am doing is creating a thread creation library for x86 machine, and deciding whether it's best to use the heap (with malloc) or the stack to store function/variables. Thank you again. – Lucas Feb 02 '12 at 23:27
  • Think of the memory as just a veeeery long line, like in math. Every integer point on the line is an address. Now you can say, to do things like function calls I need a dedicated area, so you somehow declare *my stack spans from point A to B*. Within this area, you now "have" your stack. Everything outside it is the heap. Now since the stack is limited in size from the beginning, you can actually write beyond its end, that's a *stack overflow* :-) On modern systems/CPUs, the memory is usually set up in such a way that... – DarkDust Feb 03 '12 at 07:01
  • ... the memory right before and after the stack area is marked as read-only. If you write beyond the end of the stack, the CPU says to the OS *you're not allowed to write here*, and the OS may tell the program about it or simply crash it (on Unix, you get the famous *segmentation fault* in this case). If you've got multiple threads each thread gets its own stack. So a program may have multiple stacks but each threads knows only one (to be more precise, they are called *call stacks* since they are used for function calls as opposed to general purpose stacks that you may have anywhere you like). – DarkDust Feb 03 '12 at 07:09
2

Generally, malloc memory is not allocated from the stack but from the heap.

500 - Internal Server Error
  • 28,327
  • 8
  • 59
  • 66
  • So if I wanted to create another thread using malloc, I would be pushing the function and variables into the heap? Not the stack? Is it better to use alloca for this instead? – Lucas Feb 02 '12 at 23:02
0

The pointer returned contains the address of the beginning of the allocated memory on the HEAP. malloc'd memory is not on the stack. If the memory is being used as an array, then you would push from the beginning - the [] operator on an array is just an offset from the starting pointer.

kitti
  • 14,663
  • 31
  • 49
0

Usually we have this case:

.data | .bss | heap ->   ||    <- stack

We have first non-zero initialized (.data section) static objects and zero initialized (.bss section) static objects, then the heap (allocated objects by malloc) and then the stack (automatic objects). The stack grows downwards and the heap grows upwards. (The stack usually grows downwards but on some systems it grows upwards.)

Note that C has doesn't require a stack.

ouah
  • 142,963
  • 15
  • 272
  • 331
  • So if I wanted to create another thread using the stack. Having the function and variables, would this be pushed directly to the stack or would it be wiser to use malloc and the heap? – Lucas Feb 02 '12 at 23:06