ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
malloc() and free() don't work the same way on every O/S.
I've created my own virtual memory system for a project I was working on called TinyMAZE. It's basically a wrapper for the stdlib malloc/free/etc. functions, but adds some features like detecting memory leaks, providing a volatile stack, etc. Here's the source code for it if you want to poke around and see how I did it. Basically it keeps information for each allocation in a struct. Then it malloc()'s the amount of memory requested and prepends the address of the struct instance for that allocation to the beginning of that memory block. That way when someone mvm_free(some_ptr) is called, the information for that allocation can be found at some_ptr - PTR_SIZE.
Anyway, it's not impossible for a real dynamic memory allocation implementation to work the same way. I'm pretty sure they all use some sort of header attached to the returned chunk of memory.
Your process has a region of memory, from address x to address y, called the heap. All your malloc'd data lives in this area. malloc() keeps some data structure, let's say a list, of all the free chunks of space in the heap. When you call malloc, it looks through the list for a chunk that's big enough for you, returns a pointer to it, and records the fact that it's not free any more as well as how big it is. When you call free() with the same pointer, free() looks up how big that chunk is and adds it back into the list of free chunks(). If you call malloc() and it can't find any large enough chunk in the heap, it uses the brk() syscall to grow the heap, i.e. increase address y and cause all the addresses between the old y and the new y to be valid memory.
brk() must be a syscall; there is no way to do the same thing entirely from userspace.
I have a similar question.
After we free a chunk of allocated memory,as aluser said, will go to the list of free chunks. My question is, if this free chunk is available only for this process or will it be given back to the kernel for allocations to other process, if they are in need of it?
I am using kernel 2.4. I am encountering some problems with my allocations and freeing. My process continuosly allocated chunks of 2M memory and frees it. My observation from "top" output is that the memory occupied by my process keeps on growing and stabilises at one level. It nevers shrinks. First i thought it to be a memory leak, but i have used tools for detecting leaks and found that there is no leak. Can anybody explain why this happens or give a pointer to some good writeups on this issue?
Can we rely on the "top" output for seeing the memory occupied by the process? Wat exactly happens after we free the memory?
brk() can be used to shrink the heap as well as grow it. When this happens, y decreases. You can have situations where most of the heap is free, but it can't be shrunk because some chunk at the top of it (near y) isn't free; in this case, the process hogs a lot of memory it doesn't really need. Alternatively, the malloc and free could just decide to keep the heap a certain size and not make it any smaller, on the theory that brk() can be slow and you're likely to need the memory again. I don't know how they tend to be implemented in practice.
You should look into some malloc debugging tools if you're trying to hunt down a memory leak; I've used dmalloc, I'm sure there are others too.
btw, it should be noted that what I've described in my other post doesn't have to be *the* way it works everywhere, but it's true for unixy systems at a minimum.
Try running strace on your program (strace ./myprog) and you can see the brk/sbrk system calls. If you do something like printf() you will see write() system calls also so you can tell when the brk/sbrk calls are happening relative to other parts of your program. strace can be an excellent debugging tool.