> On Thu, Nov 22, 2001, Yedidyah Bar-David wrote about "Re: Mem Leak Tracer (monitored >malloc)": > > Hi > > > > I never used any of them, so I can't comment. > > > > For my needs, ElectricFence is good enough. It is tiny, I understand > > perfectly how it works, and what I can expect from it. Most others > > are much bigger. The extreme is checker (package gccchecker in debian), > > which puts some checks inside all memory access in your code (I think). > > > > It's standard in RH and Debian, probably others. Read efence(3). > > I thought the original poster was after a memory *leak* checker. > According to efence's manual, > > "Electric Fence helps you detect two common programming > bugs: software that overruns the boundaries of a malloc() > memory allocation, and software that touches a memory > allocation that has been released by free()." > > These are buffer overflows, not memory leaks. A memory leak is when you > allocate some memory, and then forget to free it (often you even overwrite > the pointer and have no way of reaching that piece of memory during the > lifetime of your process). Programs that have memory leaks usually do not > show any bugs (hence they are hard to find), but the symptom is that their > memory usage grows over time, sometimes slightly and sometimes considerably - > this is very bad for programs which are supposed to run for a very long time, > or repeat some task over and over many times. > > A memory leak checker should show you the list of memory areas that have > never been freed when the program ends, and for each block exactly where it > was allocated (showing a stack trace, like in the debugger). > > My favorite memory leak finder was unfortunately never ported to Linux or > the x86: it is Digital's "Third Degree" for the Alpha CPU. Digital's research > people (if I remember correctly, the same guy who started Altavista later) > wrote (for the Alpha CPU) a generic tool called "atom" which takes a ready > binary and "instruments" it. "Third Degree" was one of the instrumentations > that atom could do, and it let you > 1) Find memory leaks > 2) Find buffer overflows without too much memory overhead (the CPU overhead, > while considerable, was tolerable) > 3) Find cases where you try to read memory that was never initialized (this > came in extremely handy in finding bugs that were so "stealthy" they would > have very little chance of being caught otherwise - normally it's only > easy to catch these bugs if what you're reading is a pointer) > 4) Freeing the same memory twice, freeing non-malloced memory, using freed > memory, and such things. > > I have yet to see a program for Linux that can do all those things. Maybe > purify (though I haven't used purify in many years, so I don't remember), > but that isn't free. But I must admit that I didn't try all these programs > on the original poster's list, so I'll be interested to read the replies too > (the signature below is a little relevant here ;) ). >
I believe this is one reason there are many `memory leak detectors' on /.: each is meant to detect some of the `leaks' that were mentioned above. Another reason is the way they are used: some are wrapping and/or replacing the ordinary C lib allocation procedure, either when compiling the program and/or while the process is run while others do their work on run time using other methods. As far as I know there is no one method that can detect all the possible `leaks', at least not with the x86 platform. An introductory text I know of for this thread is `Linux Application Development', chapter 6 (Memory Debugging Tools). BTW: I believe that Debian has an ebook package by that name. I have still have not looked into it. I wonder if it has something to do with the above mentioned paper bound book. > > -- > Nadav Har'El | Thursday, Nov 22 2001, 8 Kislev 5762 > [EMAIL PROTECTED] |----------------------------------------- > Phone: +972-53-245868, ICQ 13349191 |It is better to be thought a fool, then > http://nadav.harel.org.il |to open your mouth and remove all doubt. > > ================================================================= > To unsubscribe, send mail to [EMAIL PROTECTED] with > the word "unsubscribe" in the message body, e.g., run the command > echo unsubscribe | mail [EMAIL PROTECTED] > -- Shaul Karl email: shaulka (replace these parenthesis with @) bezeqint, delete the comma and the white space characters and add .net ================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
