Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
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 | |
We also thank MIT for the use of their facilities. |