[880] in testers
Re: emacs
daemon@ATHENA.MIT.EDU (daemon@ATHENA.MIT.EDU)
Fri May 25 05:38:15 1990
Date: Fri, 25 May 90 05:37:49 -0400 (EDT)
From: John F Carr <jfc@ATHENA.MIT.EDU>
To: testers@ATHENA.MIT.EDU
In-Reply-To: <YaLDcB4GG01p4anL46@athena.mit.edu>
Let me try that again, this time without hitting "send" before I finish
composing the message.
I have a core dump from the 7.0D VAX emacs in
achates:/u1/dumps/core.emacs.vax. I got this dump with gcore (the emacs
process needed SIGKILL to kill it).
I had deiconfied the emacs window a few tens of seconds before, and
still it wasn't redrawing. Then I noticed it was eating 99% of CPU
time. At this point I stopped it, gcored it, and restarted it. CPU
time printed by ps went down to 0, but in reality it was still using
99%+ -- most of it kernel time. Here's the stack trace:
_malloc_usable_size(1d) from _malloc+59
_malloc(-d35c) from _XtMalloc+c
_XtMalloc(-d35c) from _XtRealloc+14
_XtRealloc(0,-d35c) from _EmacsConvertSelection+82
_EmacsConvertSelection(cef08,7fffd01c,7fffcb38,7fffcaf8,7fffcaf4,7fffcaf0,7fffc
aec) from 412ec
_XtAppGetSelectionTimeout(11d648,7fffd004,6a,80,cef08,7fffcb48) from 4156a
_XtAppGetSelectionTimeout(cef08,11d648,7fffd004,7fffcbcc) from 3a83f
_XtWindowToWidget(7fffd004,cef08,0,a5f0c) from 3ab76
__XtOnGrabList(7fffd004) from _XtDispatchEvent+1f
_XtDispatchEvent(7fffd004) from _internal_socket_read+44
_internal_socket_read(7fffd0b4,1000) from _XTread_socket+d
_XTread_socket(0,7fffd0b4,1000) from _input_available_signal+54
_input_available_signal(17,0,7fffe120,f09a) from 7fffe87e
sigtramp(17,0,7fffe120,f09a) from _select+6
_select(20,7fffe170,0,7fffe16c,7fffe174) from 3336e
_wait_reading_process_input(0,-1,1) from _kbd_buffer_get_char+61
_kbd_buffer_get_char() from ebe2
_get_char(1) from _read_key_sequence+59
_read_key_sequence(7fffe24c,1e,0,0) from _command_loop_1+e4
_command_loop_1() from _internal_condition_case+98
_internal_condition_case(e59a,10a1cfc,e1ae) from _command_loop_2+17
_command_loop_2(10a1c0c) from _internal_catch+66
_internal_catch(10a1ce8,e3fc,10a1c0c) from _command_loop+4d
_command_loop() from _Frecursive_edit+93
_Frecursive_edit() from db97
_main(1,7fffe424,7fffe42c) from start+3c
For some reason, emacs tried to malloc a negative size. It decided how
much space it needed to get this, and called sbrk() to get it. The sbrk
call (with a negative argument) set back the data area limit to much
less that emacs was using. Normally, this would cause a core dump next
time it tried to read beyond the new end. However, emacs uses its own
version of malloc. This version calls sigsetmask(-1) to protect
morecore from getting signals. So, the following sequence happened:
start:
read a byte
segmentation violation -- trap to kernel
kernel checks signal mask, queues a signal since the current signal is blocked
kernel re-executes instruction which caused signal
goto start
It is not clear why emacs needs its own malloc; substituting the libc
malloc should fix this (make it dump core instead of hang).
