How to best check for memory leaks?

[registering]

Hi all,
How can I check that memory I free() is actually free()? That is, after program#1 finishes, how do I ensure all the memory it used is now available for others to use? I don't think I can do it via 'ps' (can I?). I can display what's located at a particular memory address with program#2 after program#1 completes, but how do I know if that memory is still being used or flagged as unusable by the OS?
Thanks!
Josh

[goon12]

I haven't tried this yet, but I read something about it and it got good reviews..
ValGrind - http://developer.kde.org/~sewardj/

[siqe]

Once the program terminates all memory is freed to the operating system regardless of whether you free it or not. However here is some software that does memory profiling. I've not tried this software but it might help http://www.gnome.org/projects/memprof/ .

[evac-q8r]

First do "top" command and find the process ID (PID) of the process. You can use "ps" command to determine the (PID) as you probably well know. Execute the less command where PID is the actual PID #: prompt% less /proc/PID/status You should get an output similar to the following:Name: project
State: S (sleeping)
Tgid: 8261
Pid: 8261
PPid: 8144
TracerPid: 0
Uid: 500 500 500 500
Gid: 500 500 500 500
FDSize: 256
Groups: 500
VmSize: 1740 kB
VmLck: 0 kB
VmRSS: 712 kB
VmData: 88 kB
VmStk: 12 kB
VmExe: 16 kB
VmLib: 1552 kB
SigPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 8000000000000000
SigCgt: 0000000008084002
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000 You will notice all of the entries beginning with Vm. This is virtual memory. You are probably most interested in VmData. Linux gives you the illusion that your process actually resides in "physical" memory although I'm not entirely sure how all this works. There is a system function which you may call within your C program which will output the contents of a system command from the running program. Basically, you would do something like:
system("less /process/PID/status").The output from this command should go to standard output, in other words, output to the terminal. Don't forget that PID above is the actual (#) Example:system("less /process/1234/status")
However, the tricky part will be to obtain the PID # and put it in the system command within the running process. Shouldn't be too hard though. Once you have that part figured out, call the system function before and after you allocate the memory originally (within the program) and then before and after you free the memory, if that makes any sense to you. Take the differences, and if they are the same (presumably) then supposedly your memory has been "freed." :)

EVAC

[scinerd]

Redhat comes with a tool called memprof. I have one used it once for to see what it did but I think it will do what you want.

[binaryDigit]

Originally posted by goon12
I haven't tried this yet, but I read something about it and it got good reviews..
ValGrind - http://developer.kde.org/~sewardj/
this is an excellent program to use.
you can also use it to improve the efficiency of your code.

[bwkaz]

Once your program exits, all its memory IS freed. No matter what. :)

While your program is running, the tools mentioned will work. But once it's done, none of them will.

[registering]

Thanks for all the great info! I thought there
were some circumstances where memory might
get stuck in a certain state even after a program exits, such as a crash, which is why I asked. I'll be sure to give all of the above a try. As always, this board rocks! :)

[bwkaz]

Originally posted by registering
I thought there were some circumstances where memory might get stuck in a certain state even after a program exits, such as a crash, which is why I asked. Nope. :) The kernel is smarter than that. At least, it has been in my experience.

Plus, the OOM killer (the piece of code that decides when the system is out of both physical RAM and swap space, and kills off processes that are using the most memory) depends on this working, even after a crash of sorts -- it sends a signal to the process that it decides to kill that can't be caught, and can't be ignored -- this signal ALWAYS causes the process to exit, immediately (the signal's name is SIGKILL, which may sound familiar). After the process dies, the kernel frees up the memory it was hogging.