🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: gnu.emacs.bug
Article #98821

GNU emacs 18.57 crashes after "fixed up unaligned data access"

#98821
From: Nick Caruso
Date: Wed, 06 Mar 1991 16:51
46 lines
2791 bytes
In GNU Emacs 18.57.1 of Wed Feb 27 1991 on beast (berkeley-unix)

I submitted a bug report a while ago about emacs 18.55 crashing on a
decstation, after being used to edit several large files, plus there
were some large non-file associated buffers hanging around.
Running dbx on the core-pse, the where command claimed that the program
had died in some routine in alloc.c (there were several, make_uninit_string
being among the most popular, with "vector" appearing sometimes, etc.)

You suggested I try using 18.57, and to let you know if the error went
away.  Well, 18.57 is better, but there are still problems.  I have
a sequence of files and operations which will always crash the 18.55 emacs.
18.57 survives this.  So I have continued to beat on an instance of 18.55 
to see how it fared.  After a couple of days of heavy use (I leave a lot 
of buffers hanging around) it got the following error:


     beast::/u/nick (74)% /fs/local/gnu/emacs-18.57/bin.MIPS/emacs &
     [1] 26136
     beast::/u/nick (75)% Fixed up unaligned data access for pid 26136 (emacs) at pc
     0x43d928
     pid 26136 (emacs) was killed on unaligned access, at pc 0x43d834

I noticed this because the emacs itself became unresponsive (even to
ctrl-g's).

This error message is sort of a wierd one, because although ultrix
*claims* to kill the process (*after* it so helpfully fixed up the
unaligned access), it does not actually do so (we run Franz inc's
Allegro Common Lisp, and it used to get these messages and survive
indefinitely although brokenly).  This emacs finally died of an
illegal instruction and dumped core.  Using dbx to do a where was
unenlightening.  I should add also that the emacs kept running for
some time after the above message, and only died after I sent it a
whole bunch of signals (IOT, TRAP, BUS, SEGV) one at a time, hoping to
cause it to core dump in some useful state.  It may have kept running
forever if I hadn't... it was chewing up cpu at a fair clip before it
died.


 thanks,

--nick caruso
  icad inc, 201 broadway
  peoples republic of cambridge, MA 02139-1901
  internet: nick@icad.com / UUCP: ...uunet!icad.com!nick
Technical Details
Message-ID: <9103061651.AA26749@beast.icad.com>
Path: arc1-ca.pugleaf.net!gmdzi!unido!mcsun!uunet!tut.cis.ohio-state.edu!unreplyable!garbage

Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: fb2f1,f3a9fdecb8273f30,start
X-Google-Attributes: gidfb2f1,public
X-Google-ArrivalTime: 1991-03-07 05:00:13 PST
Path: arc1-ca.pugleaf.net!gmdzi!unido!mcsun!uunet!tut.cis.ohio-state.edu!unreplyable!garbage
From: nick@icad.com (Nick Caruso)
Newsgroups: gnu.emacs.bug
Subject: GNU emacs 18.57 crashes after "fixed up unaligned data access"
Message-ID: <9103061651.AA26749@beast.icad.com>
Date: 6 Mar 91 16:51:47 GMT
Sender: daemon@tut.cis.ohio-state.edu
Distribution: gnu
Organization: GNUs Not Usenet
Lines: 46
Approved: bug-gnu-emacs@prep.ai.mit.edu