🚀 go-pugleaf

In GNU Emacs 18.57.8 of Fri Feb 22 1991 on lycus (berkeley-unix)

I've seen this particular coredump on both a VAX running 4.3BSD (sort
of) and an IBM RT/PC running AOS 4.3.  It happens while starting up
gnus (version 3.13).  Here's a stack trace from one of the coredumps,
this one on a VAX:

#0  0x501e4 in kill (7377, 4)
#1  0x501c9 in abort ()
#2  0x25fe7 in mark_object (objptr=(int *) 0x7fffde94) (alloc.c line 1136)
#3  0x25b4d in Fgarbage_collect () (alloc.c line 846)
#4  0x2e7c9 in Ffuncall (nargs=2, args=(int *) 0x7fffd6dc) (eval.c line 1632)
#5  0x38a22 in Fbyte_code (bytestr=-2146394940, vector=-2079284216, maxdepth=28) (bytecode.c line 270)
#6  0x2e2db in Feval (form=84974780) (eval.c line 1413)
#7  0x2c704 in Fprogn (args=84974772) (eval.c line 305)
#8  0x2ef24 in funcall_lambda (fun=84974980, nargs=0, arg_vector=(int *) 0x7fffd918) (eval.c line 1838)
#9  0x2eb68 in Ffuncall (nargs=1, args=(int *) 0x7fffd914) (eval.c line 1728)
#10 0x38a22 in Fbyte_code (bytestr=-2146394924, vector=-2079289656, maxdepth=7)(bytecode.c line 270)
#11 0x2e2db in Feval (form=84974828) (eval.c line 1413)
#12 0x2c704 in Fprogn (args=84974836) (eval.c line 305)
#13 0x2ef24 in funcall_lambda (fun=84974740, nargs=0, arg_vector=(int *) 0x7fffdb10) (eval.c line 1838)
#14 0x2eb68 in Ffuncall (nargs=1, args=(int *) 0x7fffdb0c) (eval.c line 1728)
#15 0x38a22 in Fbyte_code (bytestr=-2146399412, vector=-2079307640, maxdepth=9)(bytecode.c line 270)
#16 0x2e2db in Feval (form=84970308) (eval.c line 1413)
#17 0x2c704 in Fprogn (args=84970300) (eval.c line 305)
#18 0x2ef24 in funcall_lambda (fun=84970404, nargs=0, arg_vector=(int *) 0x7fffdd10) (eval.c line 1838)
#19 0x2eb68 in Ffuncall (nargs=1, args=(int *) 0x7fffdd0c) (eval.c line 1728)
#20 0x38a22 in Fbyte_code (bytestr=-2146539804, vector=-2079581304, maxdepth=11) (bytecode.c line 270)
#21 0x2e2db in Feval (form=84829932) (eval.c line 1413)
#22 0x2c704 in Fprogn (args=84829756) (eval.c line 305)
#23 0x2f190 in unbind_to (count=3) (eval.c line 1914)
#24 0x38a8f in Fbyte_code (bytestr=51316032, vector=67928008, maxdepth=5) (bytecode.c line 286)
#25 0x2e2db in Feval (form=84830044) (eval.c line 1413)
#26 0x2c704 in Fprogn (args=84830012) (eval.c line 305)
#27 0x2ef24 in funcall_lambda (fun=84829772, nargs=1, arg_vector=(int *) 0x7fffe098) (eval.c line 1838)
#28 0x2eb68 in Ffuncall (nargs=2, args=(int *) 0x7fffe094) (eval.c line 1728)
#29 0x2c19d in Fcall_interactively (function=17480836, record=17321996) (callint.c line 447)
#30 0x13178 in Fcommand_execute (cmd=17480836, record=17321996) (keyboard.c line 1670)
#31 0x122c1 in command_loop_1 () (keyboard.c line 773)
#32 0x2d755 in internal_condition_case (bfun=(int (*)()) 0x11d1a <command_loop_1>, handlers=17322236, hfun=(int (*)()) 0x11918 <cmd_error>) (eval.c line 1006)
#33 0x11c03 in command_loop_2 (17321996) (keyboard.c line 530)
#34 0x2d2fa in internal_catch (tag=17322216, func=(int (*)()) 0x11be6 <command_loop_2>, arg=17321996) (eval.c line 815)
#35 0x11bcc in command_loop () (keyboard.c line 512)
#36 0x118ae in recursive_edit_1 () (keyboard.c line 397)
#37 0x1184a in Frecursive_edit () (keyboard.c line 379)
#38 0x11321 in main (argc=3, argv=(char **) 0x7fffe438, envp=(char **) 0x7fffe448) (emacs.c line 490)

My suspicion is that *somewhere* in the code is forgetting to protect
against garbage collecting in the middle of an operation that leaves
a lisp object in an inconsistent state, and garbage collecting kicks
in, finds a listp object with an unknown type, and abort()s.  I don't
know enough about the code to know how to find the code that's not
protecting as it should.

Assuming that there are only a few places in the code that forget to
protect against GCing when they should, it seems likely to me that
this is related to my previous bug report about a short keyboard macro
causing emacs to coredump.

I would be glad to provide the emacs binary that generated this
coredump, the core file from this coredump, or even an account on our
system on which to debug this problem, to anyone at the FSF that wants
to work on this.

Jonathan Kamens			              USnail:
MIT Project Athena				11 Ashford Terrace
jik@Athena.MIT.EDU				Allston, MA  02134
Office: 617-253-8085			      Home: 617-782-0710