Path: utzoo!utgpu!watmath!uunet!tut.cis.ohio-state.edu!GAAK.LCS.MIT.EDU!map From: map@GAAK.LCS.MIT.EDU (Michael A. Patton) Newsgroups: gnu.emacs.bug Subject: Strange occurance in rmail Message-ID: <8811292336.AA17591@gaak.LCS.MIT.EDU> Date: 29 Nov 88 23:36:54 GMT Sender: daemon@tut.cis.ohio-state.edu Distribution: gnu Organization: GNUs Not Usenet Lines: 79 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:")