/debug size

[Thomas P. Mitchell]

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 at odin.SGI.COM> mitch at rock.sgi.com (Thomas P. Mitchell) writes:
>In article <8907161727.AA17013 at anaconda.Stanford.EDU> bul at 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 at csd.sgi.com, UUCP:  {decwrl,ucbvax}!sgi!mitch )
Rainbows -- The best (well second best) reason for windows.