This question already has answers here:
How to check heap size for a process on Linux
(5 answers)
Closed 9 years ago.
Actually my code has malloc. I'm using ubuntu OS and I want to know how much heap memory is used?
Is there any command by which I can find how much heap a running process has used in ubuntu OS?
Say now the malloc is in infinite loop and it is running in one terminal and using another terminal I would like to know how much Heap memory is occupied by that running process
you can use /proc file system
/proc/pid/shmam
It will tell you exactly how much memory it is using at that time.
for detailed inputs refer
https://serverfault.com/questions/48582/how-is-memory-usage-reported-in-linux
How to measure actual memory usage of an application or process?
If you really want to know what amount of memory your application actually uses, you need to run it within a profiler. For example, valgrind can give you insights about the amount of memory used, and, more importantly, about possible memory leaks in your program.
look into,
http://valgrind.org/docs/manual/mc-manual.html
Valgrind is basically an x86 emulator that checks all reads and writes of memory, intercepts all calls to allocate and deallocate memory. The memcheck tool of valgrind can detect the following:
1) Use of uninitialised memory,
2) Reading/writing memory after it has been free'd
3) Reading/writing off the end of malloc'd blocks
4) Reading/writing inappropriate areas below the stack.
5) Memory leaks
6) Mismatched use of malloc/new/new[] vs free/delete/delete[]
7) Overlapping src and dst pointers in memcpy() and related functions
8) Doubly freed memory
9) Passing unaddressable bytes to a system call
Related
This question already has answers here:
Does malloc reserve more space while allocating memory?
(3 answers)
Closed 3 years ago.
I am writing OS independent lockless queue, so far it works great, but there is small problem with memory managment. I am not sure if its gcc problem or mine. Problem: Memory increases when element is added to list, but when element is removed from list (free(elementPointer);) memory usage don't change.
BUT when I use pthreads, N producers and M consumers (1<N<20, 1<M<20) memory usage is about ~10mb all the time (when trying to add and remove ~10kk elements), so looks like free is working.
And funny thing is that in VS 2010 (same code, no threads) free works fine, memory is released (watched task manager).
I made test, added 1kk elements, after adding all, removed one by one all elements (no threads).
Linux - 0.08 seconds
Windows ~57 seconds
Linux(without free) - 0.07 seconds
Windows(without free) - 0.9 seconds
So, the question is, why memory isn't freed in Linux C when no threads are used ?
I can post code if necessary .
GCC version: 4.4.3
On many operating systems, free() doesn't make the memory available for the OS again, but "only" for new calls to malloc(). This is why you don't see the memory usage go down externally, but when you increase the number of new allocations by threading, the memory is re-used so total usage doesn't go through the roof.
Malloc doesn't have to return memory to the operating system. Most malloc implementations on unix-like systems don't do it. Especially for smaller object sizes.
This is done for performance reasons.
I just noticed that this is potentially unclear. By "malloc" I mean the whole subsystem related to the malloc function - malloc, free, realloc, calloc and whatever special functions your libc might implement.
To oversimplify things, there are two memory managers at work in dynamic memory allocation: the OS Memory Manager, and the Process Memory Manager (which there can be more than one of). The OS Memory Manager allocates "large chunks" of memory to individual Process Memory Managers. Each Process Memory Manager keeps track of the allocated segments, as well as the "free'd segments". The Process Memory Manager does not return the free'd segments to the OS Memory Manager because it is more efficient to hold on to it, in case it needs to allocate more memory later.
I am learning to code in C. I came across the term 'memory leak'. So, I want to ask, if I wrote a simple program in C, in which malloc() is used and if I didn't free it (though I know freeing the dynamically allocated memory is a good programming practice).
Will that memory leak would be there in the system permanently?
Will the OS never use that memory again as it is sort of lost maybe?
Just consider the case where small amount of memory(100 bytes or so) is allocated, which we do while practicing.
I'm asking this because I'm running the same program multiple times for debugging, are those memory leaks harmful?
Or the OS detects the memory leak and restore it?
Any help regarding the above and related topics is appreciated.
General-purpose operating systems are designed to protect against all sorts of issues caused by misbehaving programs. That includes managing memory. The operating system maintains its own records about what memory has been provided to each process, and it reclaims that memory when the process terminates (and no other process is using it, as occurs with various shared memory).
Special-purpose “embedded” operating systems might not provide this function.
This question already has answers here:
dangers of _exit() - memory leak?
(3 answers)
Closed 9 years ago.
In C program, if there are dynamically allocated memories remained not freed after the execution of the program exit with exit(100);, do we get memory leaks problem? For example:
int main (void) {
char str1[] = "Hello World"
char *str2;
str2 = malloc(strlen(str1 + 1));
if (str2)
exit(101); // memory leaks?
free(str2);
return 0;
}
Not under modern operating systems, no. The OS automatically collects all the memory when the process dies.
In fact freeing memory can actually be detrimental for the performance if the program is exiting anyway. The reason is that calling free sometimes involves a lot of work - updating a lot of structures, touching cache lines etc. By simply exiting you don't do all this userspace nonsense and the OS takes care of actually unmapping your data.
All dyanmically allocated memory allocated using malloc needs to be freed explicitly by calling free. While your program keeps running the memory unallocated this way might be called a leak(provided it is not being used at all).However, once your program/process returns the OS simply reclaims the memory it allocated to the process. The OS does not understand leak it simply reclaims back what it gave to the process.
This depends on the operating system. All modern operating systems (to my knowledge) will free memory not explicitly freed by the C program when it has completed execution. Thus, you can get away with this without consequences under normal circumstances. In fact, there are some schools of thought that do not recommend releasing memory when program execution will end soon as it is unnecessary. However, if you happen to be dealing with old or unusual operating systems that can be dangerous. In some of those systems, it can take a restart to free the memory again.
I was wondering... suppose I've dynamically allocated an array like
array = calloc(n, sizeof(float));
or something similar. And also if n is a really large number, (~ 1 million, for arguments sake), how long would Linux take to clear the heap memory if I didn't free() it at the end? I know any OS would go around and clear un-freed and unused heap memory areas. But I assume how long it takes to do that is OS dependent.
If a process is terminated (either voluntarily or by force), all its heap memory will be reclaimed immediately by an operating system including Windows, Linux and OS X.
It would free the memory when your process has terminated. When a process termitates, all memory, open file handles and any resources opened by it, are closed by the system.
It's unlikely such a large amount of memory request will be satisfied by malloc/calloc. They are likely to return NULL.
I know any OS would go around and clear un-freed and unused heap memory areas.
No, OS doesn't look for unused heap areas. Assuming you have successfully allocated some memory dynamically (doesn't matter if it's small or large), OS doesn't de-allocate the memory for as long as the process is running, if you don't free it yourself.
When a process keeps requesting memory then it may be killed by the Out Of Memory killer on Linux.
I have two related questions hence I am asking them in this single thread.
Q1) How can I confirm if my OS is clearing un-"free"'ed memory (allocated using malloc) automatically when a program terminates? I am using Ubuntu 11.04, 32-bit with gcc-4.5.2
As per a tutorial page by Steven Summit here, "Freeing unused memory (malloc'ed) is a good idea, but it's not mandatory. When your program exits, any memory which it has allocated but not freed should be automatically released. If your computer were to somehow ``lose'' memory just because your program forgot to free it, that would indicate a problem or deficiency in your operating system."
Q2) Suppose, foo.c mallocs a B-bytes memory. Later on, foo.c frees this B-bytes memory locations and returns it to the OS. Now my question is, can those PARTICULAR B-bytes of memory locations be re-allocated to foo.c (by the OS) in the current instance OR those B-bytes can't be allocated to foo.c untill its current instance terminates ?
EDIT : I would recommend everyone who reads my question to read the answer to a similar question here and here. Both answers explain the interaction and working of malloc() and free() in good detail without using very esoteric terms. To understand the DIFFERENCE between memory-management tools used by kernel (e.g. brk(), mmap()) and those used by the C-compiler (e.g. malloc(), free()), this is a MUST READ.
When a process ends either thru a terminating signal, e.g. SIGSEGV, or thru the _exit(2) system call (which happens to be called also when returning from main), all the process resources are released by the kernel. In particular, the process address space, including heap memory (allocated with mmap(2) (or perhaps sbrk(2)) syscall (used by malloc library function) is released.
Of course, the free library function either (often) makes the freed memory zone reusable by further future calls to malloc or (occasionally, for large memory zones) release some big memory chunk to the kernel using e.g. munmap(2) system call.
To know more about the memory map of process 1234, read sequentially the /proc/1234/maps pseudo-file (or /proc/self/maps from inside the process). The /proc file system is the preferred way to query the kernel about processes. (there is also /proc/self/statm and /proc/self/smaps and many other interesting things).
The detailed behavior of free and malloc is implementation dependent. You should view malloc as a way to get heap memory, and free as a way to say that a previously malloc-ed zone is useless, and the system (i.e. standard C library + kernel) can do whatever it wants with it.
Use valgrind to hunt memory leak bugs. You could also consider using Boehm's conservative garbage collector, i.e. use GC_malloc instead of malloc and don't bother about freeing manually memory.
Most Modern OS will reclaim the allocated memory so you need not worry about that.
The OS doesn't understand if your application/program leaked memory or not it simply reclaims what it allocated to an process once the process completes.
Yes freed memory can be reused(if needed) & the reuse can happen in the same instantiation.
Q1. You just have to assume that the operating system is behaving correctly.
Q2. There is no reason why the bytes can't be reallocated to foo.c it just depends on how the memory allocation routines work.
Q1) I'm not sure about how you can confirm. However, about the second paragraph, it's considered good style to always free whatever memory you allocate. A good explanation of this is found here: What REALLY happens when you don't free after malloc?.
Q2) Definitely; those bytes are usually the first to be reallocated (depending on the malloc implementation). For a great explanation, see: How do malloc() and free() work?.