home *** CD-ROM | disk | FTP | other *** search
Wrap
Received: from sloth.swcp.com (sloth.swcp.com [198.59.115.25]) by nacm.com (8.6.10/8.6.9) with ESMTP id KAA12964 for <executor@nacm.com>; Thu, 6 Jul 1995 10:00:23 -0700 Received: from iclone.UUCP (uucp@localhost) by sloth.swcp.com (8.6.9/8.6.9) with UUCP id LAA10369; Thu, 6 Jul 1995 11:00:22 -0600 Received: from beaut.ardi.com by mailhost with smtp (nextstep Smail3.1.29.0 #11) id m0sTuFc-000YbmC; Thu, 6 Jul 95 10:58 MDT Received: by beaut.ardi.com (linux Smail3.1.28.1 #5) id m0sTuFc-00000BC; Thu, 6 Jul 95 10:58 MDT Message-Id: <m0sTuFc-00000BC@beaut.ardi.com> Date: Thu, 6 Jul 95 10:58 MDT From: ctm@ardi.com (Clifford Thomas Matthews) To: executor@nacm.com Cc: Steve Wormley <wormley@demon.mother.com> Subject: E/L 1.99n memory growth potential workaround Sender: owner-paper@nacm.com Precedence: bulk Hi Folks, The workaround's at the end; if you're not curious as to the cause of the problem and just want the fix, skip to the bottom. Thanks to Steve Wormley, I have a handle on what's causing the memory growth under Executor/Linux 1.99n. Under UNIX filesystems, you need a path (either from / or from your current directory) to look up a file. On a Mac, you need only a directory number and a filename. We do a bunch of magic to be able to give Mac programs that (number,filename) lookup capability. Internally we have to be able to change a directory number into a path. The way we do this is keep track of all directories we ever see and then remember the name of the directory's parent. Then we can recursively climb back up to / to build a complete pathname. HOWEVER, it appears that there are a couple problems. One, there's no detection of loops in our recursive call, so if our internal database is confused, the routine that does the name resolution will repeatedly call itself forever and ever, eating up memory. I will fix this later today. In addition, when you install Executor over itself, you run the risk of confusing the database. I *think* this will fix the problem, but the code that potentially recurses forever will still be there, so please let me know if it gets triggered again. Basically you want to truncate *.dir and *.pag in the Executor library directory (probably /usr/local/lib). Here's an example, with comments on lines starting with #: beaut 4.14 su Password: # You don't necessarily need to be Super-User to do this, but you'll # want to be if the permissions on those files aren't set right beaut:/# cd /usr/local/lib/executor beaut:/usr/local/lib/executor# ls -l total 72 drwxrwxrwx 2 ctm ardi 1024 Jul 4 10:48 Configuration -rw-rw-rw- 2 ctm ardi 36864 Jul 5 21:32 DirectoryMap-le.dir -rw-rw-rw- 2 ctm ardi 36864 Jul 5 21:32 DirectoryMap-le.pag -rw-rw-rw- 1 ctm ardi 0 Nov 9 1994 DirectoryMap.dir -rw-rw-rw- 1 ctm ardi 0 Nov 9 1994 DirectoryMap.pag drwxr-xr-x 6 ctm ardi 1024 Jul 4 08:05 ExecutorVolume # There are only two files that need to be truncated, but I'll # truncate each one for illustrative purposes beaut:/usr/local/lib/executor# cat /dev/null > DirectoryMap-le.dir beaut:/usr/local/lib/executor# cat /dev/null > DirectoryMap-le.pag beaut:/usr/local/lib/executor# cat /dev/null > DirectoryMap.dir beaut:/usr/local/lib/executor# cat /dev/null > DirectoryMap.pag # done # alternatively you could have used # for f in *.dir *.pag; do > $f; done beaut:/usr/local/lib/executor# chmod a=rw *.dir *.pag # I really didn't need to reset the permissions here, but it # is important that these files are readable and writable by any # potential Executor user If there is anyone who continues to have problems after doing this, please let us know. Because of E/D 1.99n's inability to run under OS/2 and this bug, We'll continue to collect 1.99n bug reports and may release a 1.99o without any new functionality but with these (and perhaps other) showstoppers fixed. --Cliff ctm@ardi.com