[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#12466: 24.2; crash on OS X 10.7 in [EmacsView windowDidResize]
From: |
Eli Zaretskii |
Subject: |
bug#12466: 24.2; crash on OS X 10.7 in [EmacsView windowDidResize] |
Date: |
Tue, 18 Sep 2012 20:27:40 +0300 |
> From: Michael McCracken <michael.mccracken@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