GNU bug report logs -
#12466
24.2; crash on OS X 10.7 in [EmacsView windowDidResize]
Previous Next
Full log
Message #8 received at 12466 <at> debbugs.gnu.org (full text, mbox):
> From: Michael McCracken <michael.mccracken <at> gmail.com>
> Date: Tue, 18 Sep 2012 09:23:17 -0700
>
> This is a recurring issue, after several days of usage, emacs crashes
> when resizing a frame.
>
> Specifically, this is on the main screen of a two-screen setup, and I
> was resizing one of two frames.
This is not a crash, this is an abort:
> 9 libsystem_c.dylib 0x00007fff906afa7a abort + 143
> 10 org.gnu.Emacs 0x00000001001235fd Fsignal + 125
> 11 org.gnu.Emacs 0x0000000100123b89 xsignal + 9
> 12 org.gnu.Emacs 0x0000000100124015 xsignal3 + 37
> 13 org.gnu.Emacs 0x0000000100155703 scan_lists + 1539
scan_lists called xsignal3, which called abort, here:
if (gc_in_progress || waiting_for_input)
emacs_abort ();
So the question is: why did scan_lists signal an error, or why was
waiting_for_input non-zero at that time (I see no evidence that
gc_in_progress could be non-zero, but maybe some bug could have caused
that)?
The call to scan_lists seem to have been originated by evaluation of
some Lisp by display code that was invoked to handle the resize:
> 74 org.gnu.Emacs 0x0000000100022e0f safe_call + 159
> 75 org.gnu.Emacs 0x0000000100022e7e safe_call1 + 30
> 76 org.gnu.Emacs 0x0000000100022fe8 handle_fontified_prop + 360
> 77 org.gnu.Emacs 0x000000010002d92e handle_stop + 126
> 78 org.gnu.Emacs 0x0000000100040068 next_element_from_buffer + 1272
> 79 org.gnu.Emacs 0x0000000100034401 get_next_display_element + 81
> 80 org.gnu.Emacs 0x0000000100036039 move_it_in_display_line_to + 409
> 81 org.gnu.Emacs 0x000000010003a251 move_it_to + 321
> 82 org.gnu.Emacs 0x000000010003b781 move_it_vertically + 65
> 83 org.gnu.Emacs 0x0000000100059b45 Fwindow_end + 357
This bug report was last modified 12 years and 284 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.