Thank you to those that replied so quickly.
The critical clue came from Steve VanDevender
<stevev_at_hexadecimal.uoregon.edu> who pointed out that GNU emacs does
some sneaky memory tricks during load and initialization. His reply is
included below. Since we weren't looking to upgrade to a newer version
of GNU Emacs right now, we installed the sources for the GNU Emacs 19.28
which came in the OSFEMACS425 software subset. Below is the procedure
we followed and an attached patch for the shipped "config.status" script
which regenerates the config prior to building.
A) Install the FSF sources for GNU Emacs 19.28.
1) Insert the CD "Digital Unix 4.0D Associated Products - Volume 1"
into a CD-ROM drive you can access from the affected system. (This
should be part# AG-QX6FE-BE in your DU 4.0D media kit.)
1) su
2) mount -r /dev/rz13c /mnt
3) setld -l /mnt/GNUSRC/kit FSFEMACSSRC425
4) umount /mnt
B) Modify the build options to match already installed ancillary files.
1) cd /usr/opt/FSF/emacs-19.28
2) patch -b config.status FSFEMACSSRC425.patch
3) rm -f src/config.h src/paths.h
4) sh config.status
5) make
C) Install the rebuilt Emacs binary.
1) mkdir /usr/lib/emacs/lisp/site-lisp
2) installbsd -c -g bin -o bin -m 755 -s src/emacs /usr/bin/emacs.new
3) cd /usr/bin
4) mv emacs emacs.orig
5) mv emacs.new emacs
>Date: Tue, 23 Nov 1999 13:48:01 -0800 (PST)
>From: Steve VanDevender <stevev_at_hexadecimal.uoregon.edu>
>Subject: Spurious "memory exhausted" error?
In-reply-to: <4.1.19991123150001.00bf3dc0_at_pop.ameslab.gov>
>To: "Douglas C. Stephens" <stephens_at_ameslab.gov>
>Message-id: <14395.2961.308122.477710_at_hexadecimal.uoregon.edu>
MIME-version: 1.0
X-Mailer: VM 6.75 under 21.1 (patch 8) "Bryce Canyon" XEmacs Lucid
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
References: <4.1.19991123150001.00bf3dc0_at_pop.ameslab.gov>
>
>I found that after upgrading my DU 4.0E machine to patch kit 1 or
>2 (I now forget which) my local XEmacs 20.4 installation would
>also give spurious "Memory Exhausted" errors. Unfortunately C
>compiler changes that apparently also came with the patch kits
>made it difficult for me to rebuild 20.4, but I was able to build
>XEmacs 21.1.7 (and since, 21.1.8) and that no longer has the
>"Memory Exhausted" errors. I suspect that a library change in
>the patch kit had a subtle effect on malloc() that interacts
>badly with XEmacs. XEmacs (and GNU Emacs) also use a rather
>tricky "unexec" method to generate a binary with Emacs LISP code
>preloaded in the data segment, which has a variety of subtle
>portability issues.
>
>It seems /usr/bin/emacs (which I assume is the DEC-distributed
>GNU Emacs) has the same compatibility problem. Unfortuanately I
>suspect that you may just have to rebuild Emacs from source in
>order to solve it, or perhaps try digging up a copy of the C
>library from before the patch installation to link specifically
>with /usr/bin/emacs.
Original post follows:
>Date: Tue, 23 Nov 1999 15:23:43 -0600
>To: tru64-unix-managers_at_ornl.gov
>From: "Douglas C. Stephens" <stephens_at_ameslab.gov>
>Subject: Spurious "memory exhausted" error?
>
>We have two DEC3000 systems, a -700 and a -900, each configured with 128Mb
>and 256Mb primary swap. Two weeks ago we rotated each of these boxes
>out for upgrade to DU4.0d. We did fresh installs with oversized custom
>system partitions and fresh formatting as part of the install.
>
>After we installed aggregate patch kit duv40das00005-19991007 we started
>experiencing spurious errors from Emacs complaining about "Memory
>Exhausted". This would happen if we tried to invoke emacs at the shell
>prompt on an existing file requires a mode other than "Fundamental". After
>this error is given, Emacs stays running, and we can load in the file we
>want with the usual C-x,C-f command sequence. The error would manifest
>itself consistently using /usr/bin/emacs under CDE and under tty mode.
>
>When we reversed the patch kit and returned the system to baseline, this
>error didn't manifest itself. Also when we installed an older aggregate
>patch kit, duv40das00003-19981208, this error still didn't manifest itself.
>
>One other observation is that the "Memory Exhausted" error would be
>generated very quickly after Emacs executes. When the problem didn't
>happen under baseline 4.0d or under the older patch kit, Emacs would take a
>normal few seconds to load up the extra mode it needed.
>
>After comparing the two aggregate patch kits, we couldn't find a reason
>why duv40das00005-19991007 would cause Emacs to behave this way and
>duv40das00003-19981208 would not. We don't think the system is truly out
>of memory because an examination shows that under duv40das00005-19991007
>there is more available physical and virtual memory.
>
>Can anyone explain why this is happening or what we should do about it?
>We would really like to keep duv40das00005-19991007 if we can.
>
>Will summarize. TIA.
*** config.status.orig Fri Dec 30 19:49:44 1994
--- config.status Mon Nov 29 10:38:59 1999
***************
*** 36,39 ****
configuration='alpha-dec-osf3.0'
! srcdir='/usr/users/fpm/emacs-19.28'
! prefix='/usr/local'
exec_prefix='${prefix}'
--- 36,39 ----
configuration='alpha-dec-osf3.0'
! srcdir='/usr/opt/FSF/emacs-19.28'
! prefix='/usr'
exec_prefix='${prefix}'
***************
*** 44,53 ****
mandir='${prefix}/man/man1'
! infodir='${prefix}/info'
! lispdir='${datadir}/emacs/${version}/lisp'
! locallisppath='${datadir}/emacs/site-lisp'
lisppath='${locallisppath}:${lispdir}'
! etcdir='${datadir}/emacs/${version}/etc'
lockdir='${statedir}/emacs/lock'
! archlibdir='${libdir}/emacs/${version}/${configuration}'
! docdir='${datadir}/emacs/${version}/etc'
c_switch_system='-D_BSD -DDONT_CATCH_SIGNALS -Olimit 2000'
--- 44,53 ----
mandir='${prefix}/man/man1'
! infodir='${datadir}/emacs/info'
! lispdir='${datadir}/emacs/lisp'
! locallisppath='${lispdir}/site-lisp'
lisppath='${locallisppath}:${lispdir}'
! etcdir='${datadir}/emacs/etc'
lockdir='${statedir}/emacs/lock'
! archlibdir='${libdir}/emacs/bin'
! docdir='${datadir}/emacs/etc'
c_switch_system='-D_BSD -DDONT_CATCH_SIGNALS -Olimit 2000'
***************
*** 57,59 ****
C_SWITCH_X_SITE=''
! CFLAGS='-g '
X_TOOLKIT_TYPE='none'
--- 57,59 ----
C_SWITCH_X_SITE=''
! CFLAGS='-O4 '
X_TOOLKIT_TYPE='none'
***************
*** 63,65 ****
top_srcdir=''
! ac_prsub='s%^prefix\([ ]*\)=\([ ]*\).*$%prefix\1=\2/usr/local%
s%^exec_prefix\([ ]*\)=\([ ]*\).*$%exec_prefix\1=\2${prefix}%'
--- 63,65 ----
top_srcdir=''
! ac_prsub='s%^prefix\([ ]*\)=\([ ]*\).*$%prefix\1=\2/usr%
s%^exec_prefix\([ ]*\)=\([ ]*\).*$%exec_prefix\1=\2${prefix}%'
--
Douglas C. Stephens | Network/DNS/Unix/WinNT/VMS Administrator
System Support Specialist | Postmaster / Webmaster
Information Systems | Phone: (515) 294-6102
Ames Laboratory, US DOE | Email: stephens_at_ameslab.gov
Received on Mon Nov 29 1999 - 18:08:33 NZDT