🚀 go-pugleaf

In GNU Emacs 18.55.1 of Fri Oct 26 1990 on beast (berkeley-unix)

I know this is a vague report but this is a severe problem and 
any help you could give us towards a solution would be greatly 
appreciated.  

Here is the best description of the problem I can give you: I had an
emacs which had a lot of stuff loaded into it (personal customizations
and things like cl.el, an RCS package, comint, ilisp, had my RMAIL
file in a buffer, probably had GNUS hanging around, etc).  I did some
random action which caused a garbage collection.  The message area
said "Garbage collecting... done" but the emacs was hung. That is, is
would not respond in any way (I did not try ctrl-g, since I suspected
it might crash and did not want to help it out :).

After about 30 seconds, emacs went away, taking all my unsaved buffers
etc. with it.  I believe I still have the core file around.
yep, and here's some info:

dbx version 2.0
Type 'help' for help.
Corefile produced from file "emacs"
Child died at pc 0x43b2cc of signal : Segmentation fault
reading symbolic information ...
[using memory image in core]
(dbx) where
>  0 .block70 ["alloc.c":554, 0x43b2c8]
   1 make_uninit_string(length = 0) ["alloc.c":554, 0x43b2c8]
(dbx)


This problem has been seen by a number of users (mostly on
decstations) and it seems to be dependent on memory usage- i.e. users
who habitually visit enormous files (~1 megabyte or greater) see this
problem a lot more frequently.

Jonathan: could you please follow this up with bug mail to bug-gnu-emacs@prep.ai.mit.edu
with any additional information or corrections to what I've said based on your
experiences?

--thanks!

nick caruso			
icad inc, 201 broadway
cambridge, MA 02139-1901
internet: nick@icad.com / UUCP: ...uunet!icad.com!nick