[gnu.emacs.bug] Strange occurance in rmail

map@GAAK.LCS.MIT.EDU (Michael A. Patton) (11/30/88)

The following sequence of events just occured and it has me somewhat
confused.  As an aside, I have noticed quite a lot of other problems
with GNUEmacs when running out of memory but have been unable to
reproduce or describe sufficiently to report, this is the first such.
I run my machine very close to the edge on swap space (I expect to be
rearranging disk usage to fix that, but I don't have the time yet) and
am continually having programs get errors returned from malloc (or
whatever) when they can't grow any more.  GNUEmacs is probably the
best behaved UNIX program I have seen under these conditions,
congratulations.

FYI, potentially relevant information on my environment is included
after the problem description, the only point you should need to
understand this is my binding of "^Xr" to rmail and use of multiple
inboxes (in /usr/spool/mail/), each with its own rmail-file (in
~/Mail/).

I think I understand what happened and there were no long-term ill
effects, it's just that it seemed so wierd.  Perhaps you can suggest
some other way to do what I want that isn't subject to this failure,
or maybe you should just keep this type of operation in mind when
reworking movemail and related parts of the system.

----------------------------------------------------------------------
From a basically empty (a few small files) emacs:

Type "^Xr" to get rmail mode, no new mail (but I'm expecting some I
just sent to myself).  I may have run rmail before and expanded and
contracted this buffer some.

Type "i" to deal with a few messages in another inbox in the meantime.
I enter the name of the rmail file.  It loads the rmail file, says
(I'm pretty sure) "Getting new mail from..." then immediately "Memory
Exhausted".  That's not completely surprising so I type "q" intending
to come back and deal with those messages later.  It gives me back my
original rmail file (as I expected).  Since I've just been beeped that
my expected mail has arrived (and it's undoubtedly smaller than all
the messages to the other inbox), I try a "g" to get it in.

Now the wierdness, what should appear but the messages from the OTHER
inbox.  These are the ones it didn't have enough memory for a moment
ago!!  Now they fit and they've just been appended to the WRONG rmail
file.  Oh well, I ended up throwing them all away as uninteresting
anyway and then everything returned to normal (i.e. another "g" got
the messages I had expected the previous time) so it doesn't really
matter that they came in to the wrong place.


------------------------------------------------------------------------
Other possible useful background:

(insert (emacs-version)) yields:
GNU Emacs 18.50.15 of Mon Oct 24 1988 on allspice (berkeley-unix)

Lines from my .emacs which may be relevant:
; .emacs file for Michael A. Patton (map@lcs.mit.edu).

;	Copyright (C) 1988 Michael A. Patton

;; Everyone is granted permission to copy, modify and redistribute
;; this file, but only under the conditions described in the GNU Emacs
;; General Public License.  A copy of this license is supposed to have
;; been given to you along with GNU Emacs so you can know your rights
;; and responsibilities.  It should be accessable via the C-H C-C
;; command.  Among other things, the copyright notice and this notice
;; must be preserved on all copies.

;; [...]

(global-set-key "\C-xr" 'rmail)

;
; RMAIL mode
;

(setq rmail-file-name "~/Mail/RMAIL")
(setq rmail-ignored-headers "^acknowledge-receipt:\\|^acknowledge-to:\\|^address:\\|^also-known-as:\\|^aka:\\|^approved:\\|^article-i.d.:\\|^backward-references:\\|^bb-posted:\\|^bboard-id:\\|^character-type-mappings:\\|^company:\\|^compuserve-address:\\|^delivery-by:\\|^distribution:\\|^dtn:\\|^emacs:\\|^errors-to:\\|^expiration-date:\\|^expires:\\|^favorite-beer:\\|^favorite-expression:\\|^fonts:\\|^fortran:\\|^forum-transaction:\\|^forward-references:\\|^full-name:\\|^gateway:\\|^geographic-location:\\|
^home-phone:\\|^identifier:\\|^home:\\|^in-real-life:\\|^in-reply-to:\\|^keywords:\\|^length:\\|^lines:\\|^location:\\|^mail-from:\\|^mail-stop:\\|^may-qotm:\\|^mcimail-address:\\|^[a-z-]*message-id:\\|^mmdf-warning:\\|^moon:\\|^msg:\\|^network-address(es):\\|^news-[a-z-]*:\\|^nf-id:\\|^office-location:\\|^office-phone:\\|^office:\\|^office_phone:\\|^organisation:\\|^organization:\\|^origin:\\|^other_electronic_address:\\|^path:\\|^phase-of-moon:\\|^phase-of-the-moon:\\|^ph!
one-number:\\|^phone:\\|^ponder:\\
|^pony_express_address:\\|^postal-address:\\|^postal_address:\\|^posted-date:\\|^posting-version:\\|^precedence:\\|^random-quote:\\|^rank:\\|^rcvd-date:\\|^real-name:\\|^received:\\|^references:\\|^regarding:\\|^relay-version:\\|^replyto:\\|^resent-message-id:\\|^return-path:\\|^sender:\\|^song:\\|^source-info:\\|^sri-international:\\|^staff:\\|^start-date:\\|^state-of-mind:\\|^status:\\|^summary-line:\\|^summary:\\|^supersedes:\\|^telephone:\\|^telex:\\|^tel:\\|^title:\\|^transaction-entered-by:\\|^u.s.-m
ail-addrs:\\|^us-mail:\\|^usmail:\\|^usmailaddress:\\|^uucp-address:\\|^uucp-path:\\|^uucp:\\|^via:\\|^whether:\\|^word-of-the-day:\\|^work-phone-number:\\|^work-phone:\\|^work:\\|^x-location:\\|^x-mailer:\\|^x-phone:\\|^x-postal-address:\\|^x-vms-to:\\|^xref:\\|^zippy-says:\\|^zippy:")