GNU bug report logs - #7348
23.2.50; Emacs crashes on fast window resize with scrollbars on under OSX

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 7348 in the body.
You can then email your comments to 7348 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jakub Turski <yacoob <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 23.2.50;
	Emacs crashes on fast window resize with scrollbars on under OSX
Date: Sat, 6 Nov 2010 21:20:03 +0000

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)

Message #8 received at 7348 <at> debbugs.gnu.org (full text, mbox):

From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
To: Jakub Turski <yacoob <at> gmail.com>
Cc: 7348 <at> debbugs.gnu.org
Subject: Re: bug#7348: 23.2.50;
	Emacs crashes on fast window resize with scrollbars on under OSX
Date: Sun, 07 Nov 2010 12:18:26 +0900

>>>>> On Sat, 6 Nov 2010 21:20:03 +0000, Jakub Turski <yacoob <at> 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 <at> math.s.chiba-u.ac.jp

Message #11 received at 7348 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Cc: Jakub Turski <yacoob <at> gmail.com>, 7348 <at> debbugs.gnu.org
Subject: Re: bug#7348: 23.2.50;
	Emacs crashes on fast window resize with scrollbars on under OSX
Date: Sun, 07 Nov 2010 11:34:24 +0100

> 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

Message #14 received at 7348 <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Cc: Jakub Turski <yacoob <at> gmail.com>, 7348 <at> debbugs.gnu.org
Subject: Re: bug#7348: 23.2.50;
	Emacs crashes on fast window resize with scrollbars on under OSX
Date: Sun, 07 Nov 2010 12:22:22 +0100

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 <at> 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 <at> math.s.chiba-u.ac.jp
>
>

Message #17 received at 7348 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: yacoob <at> gmail.com, 7348 <at> debbugs.gnu.org, mituharu <at> math.s.chiba-u.ac.jp
Subject: Re: bug#7348: 23.2.50;
	Emacs crashes on fast window resize with scrollbars on under OSX
Date: Sun, 07 Nov 2010 21:05:23 +0200

> From: Jan Djärv <jan.h.d <at> swipnet.se>
> Cc: Jakub Turski <yacoob <at> gmail.com>, 7348 <at> 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.

Message #20 received at 7348 <at> debbugs.gnu.org (full text, mbox):

From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Jakub Turski <yacoob <at> gmail.com>, 7348 <at> debbugs.gnu.org,
	YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Subject: Re: bug#7348: 23.2.50;
	Emacs crashes on fast window resize with scrollbars on under OSX
Date: Mon, 08 Nov 2010 10:43:18 +0900

>>>>> On Sun, 07 Nov 2010 11:34:24 +0100, martin rudalics <rudalics <at> 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 <at> math.s.chiba-u.ac.jp

Message #23 received at 7348 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Cc: Jakub Turski <yacoob <at> gmail.com>, 7348 <at> debbugs.gnu.org
Subject: Re: bug#7348: 23.2.50;
	Emacs crashes on fast window resize with scrollbars on under OSX
Date: Mon, 08 Nov 2010 11:07:04 +0100

> 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

Message #26 received at 7348 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: yacoob <at> gmail.com, 7348 <at> debbugs.gnu.org, mituharu <at> math.s.chiba-u.ac.jp
Subject: Re: bug#7348: 23.2.50;
	Emacs crashes on fast window resize with scrollbars on under OSX
Date: Mon, 08 Nov 2010 21:24:27 +0200

> Date: Mon, 08 Nov 2010 11:07:04 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> Cc: Jakub Turski <yacoob <at> gmail.com>, 7348 <at> 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.

Message #29 received at 7348 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: yacoob <at> gmail.com, 7348 <at> debbugs.gnu.org, mituharu <at> math.s.chiba-u.ac.jp
Subject: Re: bug#7348: 23.2.50;
	Emacs crashes on fast window resize with scrollbars on under OSX
Date: Tue, 09 Nov 2010 08:43:20 +0100

> 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

Message #32 received at 7348 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: yacoob <at> gmail.com, 7348 <at> debbugs.gnu.org, mituharu <at> math.s.chiba-u.ac.jp
Subject: Re: bug#7348: 23.2.50;
	Emacs crashes on fast window resize with scrollbars on under OSX
Date: Tue, 09 Nov 2010 18:57:15 +0200

> Date: Tue, 09 Nov 2010 08:43:20 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: mituharu <at> math.s.chiba-u.ac.jp, yacoob <at> gmail.com, 
>  7348 <at> 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?

Message #35 received at 7348 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: yacoob <at> gmail.com, 7348 <at> debbugs.gnu.org, mituharu <at> math.s.chiba-u.ac.jp
Subject: Re: bug#7348: 23.2.50;
	Emacs crashes on fast window resize with scrollbars on under OSX
Date: Tue, 09 Nov 2010 18:52:48 +0100

> 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

Message #38 received at 7348 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: yacoob <at> gmail.com, 7348 <at> debbugs.gnu.org, mituharu <at> math.s.chiba-u.ac.jp
Subject: Re: bug#7348: 23.2.50;
	Emacs crashes on fast window resize with scrollbars on under OSX
Date: Tue, 09 Nov 2010 20:49:39 +0200

> Date: Tue, 09 Nov 2010 18:52:48 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: mituharu <at> math.s.chiba-u.ac.jp, yacoob <at> gmail.com, 
>  7348 <at> 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?

Message #41 received at 7348 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: yacoob <at> gmail.com, 7348 <at> debbugs.gnu.org, mituharu <at> math.s.chiba-u.ac.jp
Subject: Re: bug#7348: 23.2.50;
	Emacs crashes on fast window resize with scrollbars on under OSX
Date: Wed, 10 Nov 2010 08:18:45 +0100

> 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

Message #44 received at 7348 <at> debbugs.gnu.org (full text, mbox):

From: Jakub Turski <yacoob <at> gmail.com>
To: 7348 <at> debbugs.gnu.org
Subject: Re: bug#7348: 23.2.50; Emacs crashes on fast window resize with
	scrollbars on under OSX
Date: Mon, 7 Feb 2011 17:26:41 +0000

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.

Message #47 received at 7348 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jakub Turski <yacoob <at> gmail.com>
Cc: 7348 <at> debbugs.gnu.org
Subject: Re: bug#7348: 23.2.50;
	Emacs crashes on fast window resize with scrollbars on under OSX
Date: Mon, 07 Feb 2011 23:57:25 -0500

> From: Jakub Turski <yacoob <at> 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)?

Message #52 received at 7348-done <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Jakub Turski <yacoob <at> gmail.com>, 7348-done <at> debbugs.gnu.org
Subject: Re: bug#7348: 23.2.50;
	Emacs crashes on fast window resize with scrollbars on under OSX
Date: Tue, 08 Feb 2011 08:23:51 +0100

Eli Zaretskii skrev 2011-02-08 05.57:
>> From: Jakub Turski<yacoob <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.