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]

Detecting Memory Leaks



At 04:01 PM 7/15/2004, Samuel Donham wrote:
>One of my clients claims that I have a memory leak in one of our
>applications.  He claims that 'top' reports my app is slowly consuming
>more memory after running for 30 days (now 20 megs, up from 8 when it was
>first started).  Perhaps there is a memory leak, but I don't think 'top'
>is a good indicator of one ('free' would be much better).

You can also try some other display options of 'top', with the F (field) command.  You may find these fields of interest:

       RSS  The total amount of physical memory used by  the  task,  in  kilo-
            bytes,  is  shown  here.  For ELF processes used library pages are
            counted here, for a.out processes not.

       SIZE The size of the task's code plus data plus stack space,  in  kilo-
            bytes, is shown here.
       SIZE is the virtual size of the process (code+data+stack).

       TSIZE
            The  code  size  of the task. This gives strange values for kernel
            processes and is broken for ELF processes.

       DSIZE
            Data + Stack size. This is broken for ELF processes.

       TRS  Text resident size.

       SWAP Size of the swapped out part of the task.


-- 

I deliver custom Linux business applications in the Boston area.
mailto:bob(at)rsi.com, http://www.rsi.com/, 617.965.1700





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