Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

SIGKILL



On Tue, 21 Jan 2003 10:03:53 -0500
FRamsay at castelhq.com wrote:

> Mystery solved... the system ran out of memory and killed the
> software. :(
> 
> does anyone know of any good (and free) memory leak detection
> software?
Electric Fence may help. 
ftp://ftp.perens.com/pub/ElectricFence/
It is normally included as an option on Linux distros. 

Memory problems are one of the most common problems in C (and C++). Many
times a program allocates memory and does not free that memory before
the pointer goes out of scope. 
Additionally, a malloc block has additional overhead of 8 or more bytes.
And, free() rarely ever returns memory back to the system. There are
some systems (eg. Tru64 Unix) where free() does cause a negative sbrk()
under some conditions. 

I once worked on a system where the programmer did callocs (I don't
think he ever heard of malloc) to allocate variables in a function and
never had a corresponding free. This application was run as a subprocess
under IBM's TSO, so that even when the program exited, it did not return
its memory back. Result was that once you ran this program, you
virtually had to log out and log back in. 

Probably the best tool to detect memory leaks is Rational's Purify, but
that takes some big bucks. Purify instruments your program by tracking
all uses of memory, and will report, among other things, malloc blocks
allocated and never freed. It also reports misuse of memory, such as
writing to memory already freed, using unititialized automatic
variables, etc. 

-- 
Jerry Feldman <gaf at blu.org>
Boston Linux and Unix user group
http://www.blu.org PGP key id:C5061EA9
PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.blu.org/pipermail/discuss/attachments/20030121/6a9fdc5b/attachment.sig>



BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org