* bug#7348: 23.2.50; Emacs crashes on fast window resize with scrollbars on under OSX
@ 2010-11-06 21:20 Jakub Turski
2010-11-07 3:18 ` YAMAMOTO Mitsuharu
0 siblings, 1 reply; 16+ messages in thread
From: Jakub Turski @ 2010-11-06 21:20 UTC (permalink / raw)
To: 7348
Method to replicate:
1/ Compile recent OSX Emacs from 'emacs-23' branch
2/ Launch 'emacs -Q'
3/ Press: C-x 2
4/ Move your mouse to the corner of the frame, grab it, drag up,
rescaling the vertically to minimum size
Effect: Emacs crashes, if you resize it fast enough. If you resize it
slowly, it will survive. I've discovered it as I use SizeUp, program
that allows resizing OSX windows via keyboard shortcuts.
Looks like this particular problem is related to scrollbars. If I
disable scrollbars before resizing, this doesn't happen.
In GNU Emacs 23.2.50.1 (x86_64-apple-darwin10.4.0, NS apple-appkit-1038.32)
of 2010-10-17 on imacoob.nerv.local
Windowing system distributor `Apple', version 10.3.1038
configured using `configure '--prefix=/opt/local' '--with-ns'
'--without-x' '--without-dbus' 'CC=/usr/bin/gcc-4.2' 'CFLAGS=-O2 -arch
x86_64' 'LDFLAGS=-L/opt/local/lib -arch x86_64'
'CPPFLAGS=-I/opt/local/include''
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: pl_PL.UTF-8
value of $LC_CTYPE: pl_PL.UTF-8
value of $LC_MESSAGES: C
value of $LC_MONETARY: en_IE.utf-8
value of $LC_NUMERIC: en_IE.utf-8
value of $LC_TIME: en_IE.utf-8
value of $LANG: en_IE.UTF-8
value of $XMODIFIERS: nil
locale-coding-system: utf-8-unix
default enable-multibyte-characters: t
Major mode: Lisp Interaction
Minor modes in effect:
tooltip-mode: t
mouse-wheel-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
Recent input:
M-x b i g <backspace> <backspace> u g <tab> <tab> <backspace>
<backspace> <backspace> <backspace> <backspace> <backspace>
<backspace> <backspace> <backspace> <backspace> <backspace>
<backspace> <backspace> <backspace> <backspace> e m
a c s - <tab> C-w <M-backspace> r e p o r t <tab>
<return>
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Making completion list...
call-interactively: Text is read-only
Making completion list...
kill-region: The mark is not set now, so there is no region
Load-path shadows:
None found.
Features:
(shadow sort mail-extr message ecomplete rfc822 mml mml-sec
password-cache mm-decode mm-bodies mm-encode mailcap mail-parse rfc2231
rfc2047 rfc2045 qp ietf-drums mailabbrev nnheader gnus-util netrc
time-date mm-util mail-prsvr gmm-utils wid-edit mailheader canlock sha1
hex-util hashcash mail-utils emacsbug help-mode view tooltip ediff-hook
vc-hooks lisp-float-type mwheel ns-win easymenu tool-bar dnd fontset
image fringe lisp-mode register page menu-bar rfn-eshadow timer select
scroll-bar mldrag mouse jit-lock font-lock syntax facemenu font-core
frame cham georgian utf-8-lang misc-lang vietnamese tibetan thai
tai-viet lao korean japanese hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook help
simple abbrev loaddefs button minibuffer faces cus-face files
text-properties overlay md5 base64 format env code-pages mule custom
widget hashtable-print-readable backquote make-network-process ns
multi-tty emacs)
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#7348: 23.2.50; Emacs crashes on fast window resize with scrollbars on under OSX
2010-11-06 21:20 bug#7348: 23.2.50; Emacs crashes on fast window resize with scrollbars on under OSX Jakub Turski
@ 2010-11-07 3:18 ` YAMAMOTO Mitsuharu
2010-11-07 10:34 ` martin rudalics
2010-11-07 11:22 ` Jan Djärv
0 siblings, 2 replies; 16+ messages in thread
From: YAMAMOTO Mitsuharu @ 2010-11-07 3:18 UTC (permalink / raw)
To: Jakub Turski; +Cc: 7348
>>>>> On Sat, 6 Nov 2010 21:20:03 +0000, Jakub Turski <yacoob@gmail.com> said:
> Method to replicate:
> 1/ Compile recent OSX Emacs from 'emacs-23' branch
> 2/ Launch 'emacs -Q'
> 3/ Press: C-x 2
> 4/ Move your mouse to the corner of the frame, grab it, drag up,
> rescaling the vertically to minimum size
I tried this recipe with the *GTK+ build* compiled with
--enable-checking on Mac OS X 10.6.4, and I got the following
assertion failure:
.../src/xdisp.c:11515: Emacs fatal error: assertion failed: BUFFERP(w->buffer)
11511 /* If showing the region, and mark has changed, we must redisplay
11512 the whole window. The assignment to this_line_start_pos prevents
11513 the optimization directly below this if-statement. */
11514 if (((!NILP (Vtransient_mark_mode)
11515 && !NILP (XBUFFER (w->buffer)->mark_active))
11516 != !NILP (w->region_showing))
11517 || (!NILP (w->region_showing)
11518 && !EQ (w->region_showing,
The value of w->buffer was nil when the assertion failure occurred.
YAMAMOTO Mitsuharu
mituharu@math.s.chiba-u.ac.jp
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#7348: 23.2.50; Emacs crashes on fast window resize with scrollbars on under OSX
2010-11-07 3:18 ` YAMAMOTO Mitsuharu
@ 2010-11-07 10:34 ` martin rudalics
2010-11-08 1:43 ` YAMAMOTO Mitsuharu
2010-11-07 11:22 ` Jan Djärv
1 sibling, 1 reply; 16+ messages in thread
From: martin rudalics @ 2010-11-07 10:34 UTC (permalink / raw)
To: YAMAMOTO Mitsuharu; +Cc: Jakub Turski, 7348
> The value of w->buffer was nil when the assertion failure occurred.
IIUC this means the selected window was deleted and not replaced by
another window. Can you check whether this is already the case at the
time redisplay_internal is entered?
martin
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#7348: 23.2.50; Emacs crashes on fast window resize with scrollbars on under OSX
2010-11-07 10:34 ` martin rudalics
@ 2010-11-08 1:43 ` YAMAMOTO Mitsuharu
2010-11-08 10:07 ` martin rudalics
0 siblings, 1 reply; 16+ messages in thread
From: YAMAMOTO Mitsuharu @ 2010-11-08 1:43 UTC (permalink / raw)
To: martin rudalics; +Cc: Jakub Turski, 7348
>>>>> On Sun, 07 Nov 2010 11:34:24 +0100, martin rudalics <rudalics@gmx.at> said:
>> The value of w->buffer was nil when the assertion failure occurred.
> IIUC this means the selected window was deleted and not replaced by
> another window. Can you check whether this is already the case at
> the time redisplay_internal is entered?
That's not the case at the beginning of redisplay_internal, indeed.
The call to do_pending_window_change at line 11397 in xdisp.c
(emacs-23 branch) seems to change selected_window because of the
following call chain, but the variable `w' in redisplay_internal still
points to the old selected window.
redisplay_internal
-> do_pending_window_change
-> change_frame_size
-> change_frame_size_1
-> set_window_height
-> size_window
-> delete_window (/* Delete WINDOW if it's too small. */)
YAMAMOTO Mitsuharu
mituharu@math.s.chiba-u.ac.jp
^ permalink raw reply [flat|nested] 16+ messages in thread* bug#7348: 23.2.50; Emacs crashes on fast window resize with scrollbars on under OSX
2010-11-08 1:43 ` YAMAMOTO Mitsuharu
@ 2010-11-08 10:07 ` martin rudalics
2010-11-08 19:24 ` Eli Zaretskii
0 siblings, 1 reply; 16+ messages in thread
From: martin rudalics @ 2010-11-08 10:07 UTC (permalink / raw)
To: YAMAMOTO Mitsuharu; +Cc: Jakub Turski, 7348
> The call to do_pending_window_change at line 11397 in xdisp.c
> (emacs-23 branch) seems to change selected_window because of the
> following call chain, but the variable `w' in redisplay_internal still
> points to the old selected window.
>
> redisplay_internal
> -> do_pending_window_change
> -> change_frame_size
> -> change_frame_size_1
> -> set_window_height
> -> size_window
> -> delete_window (/* Delete WINDOW if it's too small. */)
That's bad. So basing redisplay_internal entirely on
struct window *w = XWINDOW (selected_window);
is inherently broken. But simply reassigning
w = XWINDOW (selected_window);
after every do_pending_window_change call is hairy since it changes the
selected window under our feet, so any things done for the window that
was selected before the call would probably have to be redone for the
now selected window. OTOH going back to retry after every call that
might have changed the selected window could get us into an infinite
loop. (BTW, do we really need up all three do_pending_window_change
calls in redisplay_internal?)
martin
^ permalink raw reply [flat|nested] 16+ messages in thread* bug#7348: 23.2.50; Emacs crashes on fast window resize with scrollbars on under OSX
2010-11-08 10:07 ` martin rudalics
@ 2010-11-08 19:24 ` Eli Zaretskii
2010-11-09 7:43 ` martin rudalics
0 siblings, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2010-11-08 19:24 UTC (permalink / raw)
To: martin rudalics; +Cc: yacoob, 7348
> Date: Mon, 08 Nov 2010 11:07:04 +0100
> From: martin rudalics <rudalics@gmx.at>
> Cc: Jakub Turski <yacoob@gmail.com>, 7348@debbugs.gnu.org
>
> > The call to do_pending_window_change at line 11397 in xdisp.c
> > (emacs-23 branch) seems to change selected_window because of the
> > following call chain, but the variable `w' in redisplay_internal still
> > points to the old selected window.
> >
> > redisplay_internal
> > -> do_pending_window_change
> > -> change_frame_size
> > -> change_frame_size_1
> > -> set_window_height
> > -> size_window
> > -> delete_window (/* Delete WINDOW if it's too small. */)
>
> That's bad. So basing redisplay_internal entirely on
>
> struct window *w = XWINDOW (selected_window);
>
> is inherently broken. But simply reassigning
>
> w = XWINDOW (selected_window);
>
> after every do_pending_window_change call is hairy since it changes the
> selected window under our feet, so any things done for the window that
> was selected before the call would probably have to be redone for the
> now selected window.
The only thing I see that uses selected_window and is done between
this line:
++redisplaying_p;
and the 1st call to do_pending_window_change is this call:
reconsider_clip_changes (w, current_buffer);
We could simply call reconsider_clip_changes again if we detect that
the selected_window changed after the call to do_pending_window_change.
The second call to do_pending_window_change is conditioned on
must_finish being zero, which I think cannot happen when this
situation hits.
And the third call to do_pending_window_change already goes back to
retry anyway.
So maybe there's no problem in updating the value of w in this case.
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#7348: 23.2.50; Emacs crashes on fast window resize with scrollbars on under OSX
2010-11-08 19:24 ` Eli Zaretskii
@ 2010-11-09 7:43 ` martin rudalics
2010-11-09 16:57 ` Eli Zaretskii
0 siblings, 1 reply; 16+ messages in thread
From: martin rudalics @ 2010-11-09 7:43 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: yacoob, 7348
> The only thing I see that uses selected_window and is done between
> this line:
>
> ++redisplaying_p;
>
> and the 1st call to do_pending_window_change is this call:
>
> reconsider_clip_changes (w, current_buffer);
>
> We could simply call reconsider_clip_changes again if we detect that
> the selected_window changed after the call to do_pending_window_change.
I suppose that would be sufficient.
> The second call to do_pending_window_change is conditioned on
> must_finish being zero, which I think cannot happen when this
> situation hits.
Well I thought must_finish being non-zero means we must neglect pending
changes while must_finish zero means we are allowed to do them. But I
don't understand redisplay_internal at all.
> And the third call to do_pending_window_change already goes back to
> retry anyway.
And if for some reason it doesn't this should not harm either.
> So maybe there's no problem in updating the value of w in this case.
In my branch I try to avoid that frame size changes may delete the
selected window. But it's non-trivial to put such behavior into the
trunk code.
Anyway, if you're going to fix this please try putting a comment there
how pause, must_finish and windows_or_buffers_changed interact and what
the entire minibuffer/echo area stuff is about.
martin
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#7348: 23.2.50; Emacs crashes on fast window resize with scrollbars on under OSX
2010-11-09 7:43 ` martin rudalics
@ 2010-11-09 16:57 ` Eli Zaretskii
2010-11-09 17:52 ` martin rudalics
0 siblings, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2010-11-09 16:57 UTC (permalink / raw)
To: martin rudalics; +Cc: yacoob, 7348
> Date: Tue, 09 Nov 2010 08:43:20 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: mituharu@math.s.chiba-u.ac.jp, yacoob@gmail.com,
> 7348@debbugs.gnu.org
>
> > The second call to do_pending_window_change is conditioned on
> > must_finish being zero, which I think cannot happen when this
> > situation hits.
>
> Well I thought must_finish being non-zero means we must neglect pending
> changes while must_finish zero means we are allowed to do them. But I
> don't understand redisplay_internal at all.
On second thought, perhaps we should simply goto retry after this
second call. I don't believe we could hit an infloop, since the
offending window was already deleted. WDYT?
> In my branch I try to avoid that frame size changes may delete the
> selected window.
How can you do that in general? What will the window display like?
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#7348: 23.2.50; Emacs crashes on fast window resize with scrollbars on under OSX
2010-11-09 16:57 ` Eli Zaretskii
@ 2010-11-09 17:52 ` martin rudalics
2010-11-09 18:49 ` Eli Zaretskii
0 siblings, 1 reply; 16+ messages in thread
From: martin rudalics @ 2010-11-09 17:52 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: yacoob, 7348
> On second thought, perhaps we should simply goto retry after this
> second call. I don't believe we could hit an infloop, since the
> offending window was already deleted. WDYT?
And the set of Emacs windows is finite, IIRC. But redisplay_internal is
so convoluted that you never know.
In any case it seems to me the most reasonable thing to do.
>> In my branch I try to avoid that frame size changes may delete the
>> selected window.
>
> How can you do that in general? What will the window display like?
When I change a frame's size I have two cases: If I can accomodate all
of its windows, I shrink them. If I can't accomodate all of them, I
make the frame's selected window the frame's root window, deleting all
other windows.
martin
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#7348: 23.2.50; Emacs crashes on fast window resize with scrollbars on under OSX
2010-11-09 17:52 ` martin rudalics
@ 2010-11-09 18:49 ` Eli Zaretskii
2010-11-10 7:18 ` martin rudalics
0 siblings, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2010-11-09 18:49 UTC (permalink / raw)
To: martin rudalics; +Cc: yacoob, 7348
> Date: Tue, 09 Nov 2010 18:52:48 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: mituharu@math.s.chiba-u.ac.jp, yacoob@gmail.com,
> 7348@debbugs.gnu.org
>
> If I can't accomodate all of them, I make the frame's selected
> window the frame's root window, deleting all other windows.
That's a bit drastic, isn't it? All we need is delete a single
window, and we end up deleting all the rest?
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#7348: 23.2.50; Emacs crashes on fast window resize with scrollbars on under OSX
2010-11-09 18:49 ` Eli Zaretskii
@ 2010-11-10 7:18 ` martin rudalics
2011-02-07 17:26 ` Jakub Turski
0 siblings, 1 reply; 16+ messages in thread
From: martin rudalics @ 2010-11-10 7:18 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: yacoob, 7348
> That's a bit drastic, isn't it? All we need is delete a single
> window, and we end up deleting all the rest?
It's not drastic because when shrinking frames I allow windows to drop
below their minimum sizes. Deletion happens only when I can't
accomodate one line/two columns windows any more. The current trunk can
delete a window when it drops below the minimum size which means that it
can delete more and sooner.
martin
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#7348: 23.2.50; Emacs crashes on fast window resize with scrollbars on under OSX
2010-11-10 7:18 ` martin rudalics
@ 2011-02-07 17:26 ` Jakub Turski
2011-02-08 4:57 ` Eli Zaretskii
0 siblings, 1 reply; 16+ messages in thread
From: Jakub Turski @ 2011-02-07 17:26 UTC (permalink / raw)
To: 7348
This bug hasn't been fixed, has it?
Just wanted to see what are the chances of having this fixed in the
next release.
KT.
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#7348: 23.2.50; Emacs crashes on fast window resize with scrollbars on under OSX
2011-02-07 17:26 ` Jakub Turski
@ 2011-02-08 4:57 ` Eli Zaretskii
2011-02-08 7:23 ` Jan Djärv
0 siblings, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2011-02-08 4:57 UTC (permalink / raw)
To: Jakub Turski; +Cc: 7348
> From: Jakub Turski <yacoob@gmail.com>
> Date: Mon, 7 Feb 2011 17:26:41 +0000
> Cc:
>
> This bug hasn't been fixed, has it?
> Just wanted to see what are the chances of having this fixed in the
> next release.
I could try fixing it as discussed near the end of this thread, but do
I have a reliable procedure for reproducing it? Is the bug OSX
specific, and if so, in what way (i.e. what OSX specific features
trigger it)?
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#7348: 23.2.50; Emacs crashes on fast window resize with scrollbars on under OSX
2011-02-08 4:57 ` Eli Zaretskii
@ 2011-02-08 7:23 ` Jan Djärv
0 siblings, 0 replies; 16+ messages in thread
From: Jan Djärv @ 2011-02-08 7:23 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Jakub Turski, 7348-done
Eli Zaretskii skrev 2011-02-08 05.57:
>> From: Jakub Turski<yacoob@gmail.com>
>> Date: Mon, 7 Feb 2011 17:26:41 +0000
>> Cc:
>>
>> This bug hasn't been fixed, has it?
>> Just wanted to see what are the chances of having this fixed in the
>> next release.
>
> I could try fixing it as discussed near the end of this thread, but do
> I have a reliable procedure for reproducing it? Is the bug OSX
> specific, and if so, in what way (i.e. what OSX specific features
> trigger it)?
It is Nextstep-specific, easy to trigger. I think most of the discussion in
this bug is about something else, that comes from trying to reproduce it on a
Gtk+-build. The crash is Nextstep-specific and now fixed.
Jan D.
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#7348: 23.2.50; Emacs crashes on fast window resize with scrollbars on under OSX
2010-11-07 3:18 ` YAMAMOTO Mitsuharu
2010-11-07 10:34 ` martin rudalics
@ 2010-11-07 11:22 ` Jan Djärv
2010-11-07 19:05 ` Eli Zaretskii
1 sibling, 1 reply; 16+ messages in thread
From: Jan Djärv @ 2010-11-07 11:22 UTC (permalink / raw)
To: YAMAMOTO Mitsuharu; +Cc: Jakub Turski, 7348
Some timing has changed. I got a crash because of BadCursor. It only happens
if you start Emacs and put the mouse fast within the frame on a non-toolkit
build. Initializing cursor to No_Cursor in note_mode_line_or_margin_highlight
fixed tha.
Jan D.
YAMAMOTO Mitsuharu skrev 2010-11-07 04.18:
>>>>>> On Sat, 6 Nov 2010 21:20:03 +0000, Jakub Turski<yacoob@gmail.com> said:
>
>> Method to replicate:
>> 1/ Compile recent OSX Emacs from 'emacs-23' branch
>> 2/ Launch 'emacs -Q'
>> 3/ Press: C-x 2
>> 4/ Move your mouse to the corner of the frame, grab it, drag up,
>> rescaling the vertically to minimum size
>
> I tried this recipe with the *GTK+ build* compiled with
> --enable-checking on Mac OS X 10.6.4, and I got the following
> assertion failure:
>
> .../src/xdisp.c:11515: Emacs fatal error: assertion failed: BUFFERP(w->buffer)
>
> 11511 /* If showing the region, and mark has changed, we must redisplay
> 11512 the whole window. The assignment to this_line_start_pos prevents
> 11513 the optimization directly below this if-statement. */
> 11514 if (((!NILP (Vtransient_mark_mode)
> 11515 && !NILP (XBUFFER (w->buffer)->mark_active))
> 11516 != !NILP (w->region_showing))
> 11517 || (!NILP (w->region_showing)
> 11518 && !EQ (w->region_showing,
>
> The value of w->buffer was nil when the assertion failure occurred.
>
> YAMAMOTO Mitsuharu
> mituharu@math.s.chiba-u.ac.jp
>
>
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#7348: 23.2.50; Emacs crashes on fast window resize with scrollbars on under OSX
2010-11-07 11:22 ` Jan Djärv
@ 2010-11-07 19:05 ` Eli Zaretskii
0 siblings, 0 replies; 16+ messages in thread
From: Eli Zaretskii @ 2010-11-07 19:05 UTC (permalink / raw)
To: Jan Djärv; +Cc: yacoob, 7348
> From: Jan Djärv <jan.h.d@swipnet.se>
> Cc: Jakub Turski <yacoob@gmail.com>, 7348@debbugs.gnu.org
>
> Some timing has changed. I got a crash because of BadCursor. It only happens
> if you start Emacs and put the mouse fast within the frame on a non-toolkit
> build. Initializing cursor to No_Cursor in note_mode_line_or_margin_highlight
> fixed tha.
Looks like it's my fault. Sorry, and thanks for fixing that.
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2011-02-08 7:23 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-11-06 21:20 bug#7348: 23.2.50; Emacs crashes on fast window resize with scrollbars on under OSX Jakub Turski
2010-11-07 3:18 ` YAMAMOTO Mitsuharu
2010-11-07 10:34 ` martin rudalics
2010-11-08 1:43 ` YAMAMOTO Mitsuharu
2010-11-08 10:07 ` martin rudalics
2010-11-08 19:24 ` Eli Zaretskii
2010-11-09 7:43 ` martin rudalics
2010-11-09 16:57 ` Eli Zaretskii
2010-11-09 17:52 ` martin rudalics
2010-11-09 18:49 ` Eli Zaretskii
2010-11-10 7:18 ` martin rudalics
2011-02-07 17:26 ` Jakub Turski
2011-02-08 4:57 ` Eli Zaretskii
2011-02-08 7:23 ` Jan Djärv
2010-11-07 11:22 ` Jan Djärv
2010-11-07 19:05 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).