From: Wen Guangcheng (wen@bs2.qnes.nec.co.jp)
Date: Wed Aug 06 2003 - 02:38:50 EDT
Hello,
Many thanks to Russell, Schrader and Morton.
By suggestion of them I am using "prstat" or "ps" to examines the memory size
of the process now and found it is quite steady.
Cheers,
--Wen
----- Original Message -----
From: <Russell_C_Page@national.com.au>
To: "Wen Guangcheng" <wen@bs2.qnes.nec.co.jp>
Sent: Wednesday, August 06, 2003 1:45 PM
Subject: Re: Question on diagnosing memory leak
>
> I check with "ps -l".
>
> Here is an example of what you MIGHT see if the program has a memory leak.
>
> $ cat sieve.c
> /* Leaks like a sieve */
>
> #include <unistd.h> /* sleep() */
> #include <stdlib.h> /* malloc() */
>
> int
> main()
> {
> int i; /* counter for safety */
> char* cp;
>
> for (i=0; i < 1000; ++i) {
> sleep(5);
> cp = (char *) malloc(1024); /* ptr cp is overwritten here
> */
> }
> return 0;
> }
>
> $ ps -l | head -1
> F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD
> $ ./sieve &
> [1] 383
> $ ps -l | grep sieve
> 8 S 1001 383 318 0 53 24 707f6728 112 707f6950 pts/0 0:00
> sieve
> $ date
> Wed Jul 16 11:56:48 EST 2003
> $ ps -l | grep sieve
> 8 S 1001 383 318 0 53 24 707f6728 112 707f6950 pts/0 0:00
> sieve
> $ date
> Wed Jul 16 11:57:20 EST 2003
> $ ps -l | grep sieve
> 8 S 1001 383 318 0 53 24 707f6728 113 707f6950 pts/0 0:00
> sieve
> $ date
> Wed Jul 16 11:57:58 EST 2003
> $ ps -l | grep sieve
> 8 S 1001 383 318 0 53 24 707f6728 114 707f6950 pts/0 0:00
> sieve
> $ kill %1
> [1] + Terminated ./sieve &
> $
>
> This program sits in a loop grabbing a 1K block of memory every 5 seconds.
> If you inspect the SZ ("Size") field in the ps listing you can see that the
> program image in memory is growing every 20 - 30 seconds or so.
>
> Two important warnings!
>
> Firstly, if you see SZ grow, all you can say is that the program possibly
> has a memory leak. It is clear from reading the source code that this
> program has a problem. The growth in the SZ field confirms something we can
> see in the source. Real programs have complicated control flows and it is
> rarely possible to spot a memory leak by inspecting source code. However,
> any program that allocates memory dynamically may exhibit this behaviour
> even if it subsequently frees the memory. It is also important to note that
> if the program frees the memory SZ doesn't shrink. SZ always reflects the
> most memory the program got from the operating system.
>
> Secondly, if SZ doesn't change the program still may have a memory leak. In
> a complicated program (and most are!) it
> is not possible to test every possible state or case the program may run
> in. So it is never possible to prove that a program has no bugs.
>
> I recently had a situation where a program that ran as an NT service on a
> Windoze NT box was leaking memory. I didn't have access to the source code,
> but what I noticed was that every 15 minutes it grew in size by 8k. I went
> back to the vendor. They had another troll through their source code and
> found the leak.
>
> Here is a program that allocates a pile of memory and gives it back.
>
> $ cat watertight.c
> /* No leak */
>
> #include <unistd.h> /* pause() */
> #include <stdlib.h> /* malloc() */
> #include <signal.h> /* signal */
>
> void
> trap(int ignore)
> {
> return;
> }
>
> int
> main()
> {
> int i;
> char* cp[1000];
>
> signal(SIGUSR1, trap);
>
> for (i=0; i < 1000; ++i) {
> cp[i] = (char *) malloc(1024);
> }
> pause();
> for (i=0; i < 1000; ++i) {
> free(cp[i]);
> }
> pause();
> return 0;
> }
> $ ./watertight &
> [1] 432
> $ ps -l | head -1
> F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD
> $ ps -l | grep water
> 8 S 1001 432 318 0 56 24 707f6728 237 707f6950 pts/0 0:00
> watertig
> $ kill -USR1 %1
> $ ps -l | grep water
> 8 S 1001 432 318 0 53 24 707f6728 237 707f6950 pts/0 0:00
> watertig
> $ kill -USR1 %1
> [1] + User Signal 1 ./watertight &
> $
>
> Notice that after the first pause() it frees the 1 meg of memory it grabbed
> in the first loop. However, we see no change in the SZ field.
>
>
> Hope this helps!
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers
This archive was generated by hypermail 2.1.7 : Wed Apr 09 2008 - 23:26:52 EDT