[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Undefined operation codes
- To: bug-EMACS@MIT-OZ, bug-Babyl@MIT-OZ
- Subject: Undefined operation codes
- From: Leonard N. Foner <TK.FONER@MIT-OZ>
- Date: Fri, 22 Jul 1983 02:24 EDT
- Cc: Tk.Foner@MIT-OZ
- Reply-to: Foner at MIT-MC
Many, many times tonight, my EMACS has unexpectedly died due to
undefined opcodes being executed at various random points.
Most of the time, it happened while inside Babyl. It happened solidly
whenever I used the ^W command, and randomly on Space and n as well.
I was reading a fairly large Babyl file, but smaller than I have
sometimes used. (I often get ?Illegal memory reference errors looking
at large files with EMACS... another bug which no one seems to have
Usually, I got messages like
?Illegal instruction 37000,,52053 at 7607
?Undefined operation code
or sometimes at address 13121. The opcode was always 37000,,52053.
Reentering sometimes worked (which left me at the normal EMACS level,
requiring a ^X r to get back into Babyl). Sometimes, a Reenter would
cause another trap at another random address. A couple of times, in
the middle of updating the screen, EMACS would die with an illegal
instruction of 0 at 0. This was, of course, unrecoverable.
Unfortunately, this is not repeatable, and I run a very customized
EMACS, including, no doubt, the new MODLIN package that just came out
(I have no idea if that has anything in the world to do with it...
I'm grasping at straws). What I'd like to be able to do is to write
out a crashdump file of my EMACS just after it's blown up, so someone
can look at its core image and find out what's going on. How can I do
This bug has bitten me every so often before now, but tonight it
happened around 20 times, which seems slightly excessive, and required
me to reset my EMACS fork roughly 8 times.
While I'm reporting bugs, by the way, I've found a bug in the EMACS
display update routines. If one has a very long single line (longer
than a screenful), searching for a string in it leaves the cursor
positioned \one line higher/ than it should be. Typing ^U^L or a
simple ^L lands the cursor where it belongs, so obviously it is the
update and not the search that is failing. This is absolutely
Thanx much, folks.