Can I cause memory leaks during debug of my program?

Question

I'm developing on Ubuntu 9.10

I'm writing a C program, during my tests & debugs I'm calling malloc and always remember to call free() - This is obviously just during debug.

I'm curious: Am I eating up the free memory the system has which each debugging session? Or does the kernel cleans up the process memory after I shutdown my application from the IDE? Logically reasoning I'm pretty sure that the kernel knows about the whole process being killed and thus knows what memory it has allocated, and thus even though the application did not call free the memory is still being released.

I would appreciate an explanation.

Thank you, Maxim.

Answer 1

是的，操作系统将在程序停止运行时回收分配给程序的所有内存。

Answer 2

You are correct.

This is not a serious concern, because any 'leaked' memory is immediately freed once the program you're debugging is terminated.

Memory leaks are generally only a concern when a process is long running.

Answer 3

The kernel has a collection of process records within the kernel's memory and keeps track of each process, the amount of memory consumed, resources such as i/o, file handles or inodes. The process records are usually held in a queue in which the kernel's task pointer points to the process record in a never ending fashion (that explains why the perception of 'multi-tasking', it is doing that a blink of an eye - so fast, really, it is doing single tasking in the eyes of the kernel). There is a field in the process record that tells how much memory is chewed up by said process.

Yes the kernel does obtain the memory back to its own pool ready for consumption by another process. Furthermore, you are absolutely 100% correct in relation to memory leaks as John Weldon above pointed out. I mentioned this in another posting , for every malloc there is a free, if there isn't you have a memory leak. So don't worry about your debugging session. That is perfectly ok as the kernel has a responsibility to ensure the memory is reclaimed.

Some applications (especially daemons) must be debugged throughly and that no memory leaks occur in it as the daemon will be running for a long time before the next reboot. Incidentally, it was mentioned in my favourite book 'Expert C Programming, Deep C Secrets - Peter Van Der Linden', that at one stage when he was in Sun, there was a tool called 'printtool' for printing, but every so often the queue jammed up because there was a memory leak in the print spooler program and the reboot of the Sun machine cured it, he describes that in detail in relation to memory leaks.

Hope this helps, Best regards, Tom.

Answer 4

A lot of old Unix apps leaked memory badly, and counted on the end-of-process cleanup. Even in the limited address space of those days, it generally worked reasonably well. This doesn't work with long-running apps, of course. I wouldn't worry about the effects of memory leaks when debugging (the leaks themselves are bugs, so you'll want to remove them before releasing).

What happens in Unix, and all other current OSs that I'm actually familiar with, is that the OS assigns memory to a process. malloc() grabs memory out of the process memory, and if it asks for more than the process can provide will ask for more process memory from the OS. If the program's got a memory leak, the process memory can grow as large as the system will allow, but it's all process memory, and all the allocation will go away when the process ends.

I understand there have been OSs that didn't recover memory from a terminated process, but I haven't seen one or worked on one. The only OSs for personal computers (as opposed to special purpose or enterprise computers) that significant numbers of people use are Windows and Unix variants, and those will release all memory at the end of the process.