Path: utzoo!attcan!uunet!lll-winken!arisia!sgi!shinobu!odin!rock!mitch From: mitch@rock.sgi.com (Thomas P. Mitchell) Newsgroups: comp.sys.sgi Subject: Re: /debug size Summary: Looking for memory leak, After cooling my but and hands in cold water. Message-ID: <221@odin.SGI.COM> Date: 18 Jul 89 22:11:39 GMT References: <8907161727.AA17013@anaconda.Stanford.EDU> <215@odin.SGI.COM> Sender: news@odin.SGI.COM Organization: Silicon Graphics Computer Systems, Mountain View CA. Lines: 132 One of our engineers sent me some gentle flames about my last posting. The following is a summary of his note and our discussions. Both of us were concerned about a possible memory leak in the OS or some application. My initial posting was to keep people from using the equivalent of cotton clothes line to climb mountains. Now on to a possible real problem. A memory leak in SGI code is wrong and needs to be identified so we can fix it. As I indicated /debug can return fun things. In article <215@odin.SGI.COM> mitch@rock.sgi.com (Thomas P. Mitchell) writes: >In article <8907161727.AA17013@anaconda.Stanford.EDU> bul@ANACONDA.STANFORD.EDU (Byung-Uk Lee) writes: >> >>One problem with the /debug size is that it builds up. > >are some processes that claims swap spaces even after the process is killed. > >The only way to refresh the /debug directory seems to be rebooting the machine > > Please, the size of /debug is not real. /debug is a data > structure which is used by the debugging tools to locate > running processes. Users need do nothing with it. Except > perhaps omit it in backups. > > The size is not real. Remember one of the primary goals of > Unix/Irix(1) is to reuse code. When 'dbx' was enhanced to > permit attaching running processes the model of a filesystem > was apparently selected because there was a lot of code > which was easy to reuse. As a side effect things like 'df' > could return interesting things. The nature of > 'interesting' is a result of the whims of the kernel > programer. In other words things may change. > > What is documented is the -p flag to dbx. Let us review; > /debug was designed as a hook for dbx. > ^ *PERIOD* Thom is correct in that /debug is modelled after an early version of the the AT&T /proc mechanism. He is also correct in that /debug was implemented as a facility for multiprocess/arbitrary process debugging. The /debug mechanism replaced the ptrace mechanism for process control. AT&T will be implementing /proc in the System V.4 release. The semantics of /debug may be changed or replaced by the new /proc mechanism in the future. Though Thom refers to other "artifacts" of /debug being a file system as whimsical, I counter that much of what you see is a logical extension of the file system concept. For instance do a "df -ik /debug" to show the number of inodes and display all information in 1KB blocks. For instance: Filesystem Type kbytes use avail %use iuse ifree %iuse Mounted /debug dbg 51048 16664 34384 33% 46 50 48% /debug The field "iuse" shows the number of file system inodes in use. There is one inode per process file. Thus there are 46 processes running on this system. "ifree" shows the number of available inodes left on the file system. This means I could run 50 more processes (one inode per process) on the system. The default process limit (/usr/sysgen/kernel:#define NPROC) on a 4D is 96 processes. At one inode per process, we have 96 available inodes on /debug. 46 inodes in use plus 50 inodes free equals 96 inodes. The "kbytes" field represents the total size of the swap partition (a very real size). The "use" field indicates how much of my swap partition is in use and "avail" shows the remainder. Now, lets do an "ls -lsa /debug". total 42253 4 dr-xr-xr-x 2 root sys 1568 Jul 18 10:45 . 1 drwxr-xr-x 17 root sys 512 Jul 12 17:21 .. 232 -rw------- 1 root sys 118784 Jul 12 17:20 00001 . . . 2184 -rw------- 1 root engr 1118208 Jul 12 17:26 00240 1144 -rw------- 1 ciemo engr 585728 Jul 12 17:26 00241 472 -rw------- 1 ciemo engr 241664 Jul 12 17:26 00243 2320 -rw------- 1 root engr 1187840 Jul 12 17:58 00477 464 -rw------- 1 ciemo engr 237568 Jul 12 17:58 00478 The first column (ls -s) represents the size of the process in swap in 512 byte blocks. The permissions show that only root can write into the swap partition. Imagine all of the security breaches that could occur if just anybody could write into the swap partition. No, no, no. You don't want to be able to write arbitrary data into the swap space. Notice, also, that no one else has write permissions for my process but myself. This is the permissions of the running process and all writing into the process is done on my behalf by the kernel (root). The number of links is 1 (one inode per process). The uid/gid are those of the running process. The size in bytes is the size of the virtual memory taken up by the process. The date shows the creation time of the process (a liberty taken since "ls" usually shows the last modification time). The file name is the process id. To correct Thom, these numbers are real. I hate to admit that something running on your system may be growing due to a memory leak. It would be most useful to yourself and SGI if you could watch your system and periodically note the change in size of long running processes. Try doing an "ls -s > /usr/tmp/ls.atboot" right after booting your system. If your system seems to have lost swap space "permanently", do another "ls -s > /usr/tmp/ls.chk1". You might want to sample at a couple points to get a good handle on memory usage. The representations of /debug by "ls" and "df" match up well with the concept of processes as files. The caveat here is that changes in IRIX and adoption of external standards will possibly change the semantics of these operations of /debug. > > It happens to look like a filesystem. But that makes things > like open/close/lseek etc. work in ordinary ways. Remember > the part about reusing code. > > -------- > (1) Both Trademarks. > UNIX is AT&T's > Irix is Silicon Graphics' =============================================================================== Form: 27B-6 Submitted by: Central Services Operative, DC-473 Task: Duct repair Status: Emergency =============================================================================== Thomas P. Mitchell (ARPA:mitch@csd.sgi.com, UUCP: {decwrl,ucbvax}!sgi!mitch ) Rainbows -- The best (well second best) reason for windows.