[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Mem Leak Tracer (monitored malloc)
> 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
> nyh@math.technion.ac.il |-----------------------------------------
> 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 linux-il-request@linux.org.il with
> the word "unsubscribe" in the message body, e.g., run the command
> echo unsubscribe | mail linux-il-request@linux.org.il
>
--
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 linux-il-request@linux.org.il with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail linux-il-request@linux.org.il