[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
EMACS illegal memory write
- To: jtw%MIT-OZ@MIT-MC.ARPA, shsu%MIT-OZ@MIT-MC.ARPA
- Subject: EMACS illegal memory write
- From: "Leonard N. Foner" <FONER%MIT-OZ@MIT-MC.ARPA>
- Date: Sun, 26 May 1985 15:06 EDT
- Cc: Bug-EMACS%MIT-OZ@MIT-MC.ARPA, Foner%MIT-OZ@MIT-MC.ARPA
I've complained about this problem before to Bug-EMACS, but I had
fewer specifics. No one ever answered. I suspect no one maintains
Twenex EMACS anymore.
However... this time, I think I know whose library the bug is in, and
it looks like one of you two might know how to fix whatever is going
wrong. You two are the last writers of the library file, so I presume
you are its authors.
Okay, here's the problem. For the last several months at least, my
EMACS has been prone to completely random crashes, usually having to
do with illegal memory writes and reads. Now, I couldn't understand
how EMACS was dying this way, since TECO's memory management seemed
okay, and especially because this happened much more frequently with
large files in my buffers (i.e., when my EMACS was close to URKing
Recently, though, I managed to nail down what's going on, at least
some of the time. I run the MAICHK library, and this library seems to
be responsible for the bad behavior. It seems that particular
addresses from which I get mail (probably just very long ones) cause
MAICHK to crash my EMACS when it attempts to say
[Mail waiting - 2:50pm from foo]
I was able to repeat this behavior with an EMACS empty of any buffers,
but loading my init which loads this library. It was infinitely
repeatable until someone else sent me mail---at which point it stopped
and was unrepeatable.
Now, it seems likely that this library is doing something wrong, given
that part of it is actually running machine code in a q-reg. It seems
especially so, given that I tried killing the library (with my
mailfile still last written by some address that broke things), then
exited EMACS (which forces MAICHK to update that message), and my
EMACS did NOT bomb. It only bombed when MAICHK was loaded.
Unfortunately, I don't understand enough about TECO and MIDAS to be
able to debug this problem, especially since I didn't write the code.
So... in the hopes that one of you two can look at it and maybe find
out what's going on, here's the story. In the file
OZ:<FONER.EMACS>BROKEN-EMACS.LOG there resides a log of this problem.
I had started up an EMACS, ^X^Z'ed out, and watched MAICHK apparently
trash it. I then started up a fresh one, killed the MAICHK library,
^X^Z'ed out, and watched my EMACS exit normally. The log file is a
little hard to read, given that it doesn't include the echo of my
commands (which were simply either M-X Kill Library or ^X^Z in each
case), and that it has cursor control stuff for a Heath terminal in
it. But you should be able to figure it out.
The init that was running is in the same directory as the log, and is
called EMACS.ORIGINAL-UNDUMPED-OLD-DIRED-6-MAY, and was my EMACS.INIT
file until fairly recently. (My new EMACS is a dumped EMACS; that'll
likely have its own peculiar problems.) I shall be changing my LNFLIB
library (which my init loads) shortly, but will, if I change it, leave
the old one around as OLD-LNFLIB so you can find it for debugging.
It's entirely possible that the error is reproduceable without my init
at all, simply by loading MAICHK, creating some hokey long address,
and causing the address to send you mail. When MAICHK attempts to
display the sender, either during modeline update, autosave, or EMACS
exit, it should crash. (This, by the way, explains the frustratingly
random occurrence of the errors. They were a combination of a
modeline update, which happens once a minute in my EMACS, and a long
or somehow otherwise weird address. I think.)
Thanx for any light you can shed on this. I'd like not to have to
give up using MAICHK, if that's the bug. I'd certainly like to know
if you can rule it out, in which case I'm back to ground zero and must
figure out where else the bug resides that keeps wiping out my EMACS.