[169] in Athena Bugs
Re: Another core dump
daemon@ATHENA.MIT.EDU (Mark W. Eichin)
Fri Apr 8 07:47:50 1988
Date: Fri, 8 Apr 88 06:46:47 EST
From: Mark W. Eichin <eichin@ATHENA.MIT.EDU>
To: bugs@ATHENA.MIT.EDU, bug-gnuemacs@ATHENA.MIT.EDU
In-Reply-To: Mark W. Eichin's message of Fri, 8 Apr 88 03:18:27 EST <8804080818.AA07122@OLIVER.MIT.EDU>
Well, now it is biting harder.
To demonstrate the problem quickly (and make your own core dump!):
On a vax type workstation:
attach charon:mit
attach eichin
emacs -q &
M-x load-file
/mit/eichin/elispm/jmp.el
M-x zwgc
... wait for the login notice in your other zwgc, about 5-10
seconds... or use ps -ux and wait until the emacs is definitely
idle...
from the shell: zwrite `whoami` -m foo
wait for the core dump with illegal instruction. (The backtrace shows
a call to abort.)
I get core dumps from 18.49.35G (5.5T release) and from 18.50.41G
(emacs:emacs) which show the same problem... this probably should be
forwarded to FSF... especially if we can narrow down where it is
crashing. It would also be nice to know if I can avoid the problem
somehow...
So, eichin:cores/emacs.core.apr8{.18-49} are the core dumps for 18.50
and 18.49 emacsen, respectively, both generated with emacs -q. Both
have similar stack traces.
I just tried emacs with unsetenv DISPLAY (tty mode) - same core dump.
Again, you can make one yourself... it still dies in SetBfp in
Fset_buffer in save_excursion_restore in .... somewhere within
read_process_output, indicating that it probably *is* running my
process-filter...
Mark Eichin
<eichin@athena.mit.edu>
SIPB Member & Project Athena ``Watchmaker''
