bug#7348: 23.2.50; Emacs crashes on fast window resize with scrollbars on under OSX

bug#7348: 23.2.50; Emacs crashes on fast window resize with scrollbars on under OSX

[Jakub Turski]

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)

bug#7348: 23.2.50; Emacs crashes on fast window resize with scrollbars on under OSX

[YAMAMOTO Mitsuharu]

>>>>> 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

bug#7348: 23.2.50; Emacs crashes on fast window resize with scrollbars on under OSX

[martin rudalics]

 > 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

bug#7348: 23.2.50; Emacs crashes on fast window resize with scrollbars on under OSX

[Jan Djärv]

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
>
>

bug#7348: 23.2.50; Emacs crashes on fast window resize with scrollbars on under OSX

[Eli Zaretskii]

> 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.

bug#7348: 23.2.50; Emacs crashes on fast window resize with scrollbars on under OSX

[YAMAMOTO Mitsuharu]

>>>>> 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

bug#7348: 23.2.50; Emacs crashes on fast window resize with scrollbars on under OSX

[martin rudalics]

 > 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

bug#7348: 23.2.50; Emacs crashes on fast window resize with scrollbars on under OSX

[Eli Zaretskii]

> 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.

bug#7348: 23.2.50; Emacs crashes on fast window resize with scrollbars on under OSX

[martin rudalics]

 > 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

bug#7348: 23.2.50; Emacs crashes on fast window resize with scrollbars on under OSX

[Eli Zaretskii]

> 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?

bug#7348: 23.2.50; Emacs crashes on fast window resize with scrollbars on under OSX

[martin rudalics]

 > 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

bug#7348: 23.2.50; Emacs crashes on fast window resize with scrollbars on under OSX

[Eli Zaretskii]

> 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?

bug#7348: 23.2.50; Emacs crashes on fast window resize with scrollbars on under OSX

[martin rudalics]

 > 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

bug#7348: 23.2.50; Emacs crashes on fast window resize with scrollbars on under OSX

[Jakub Turski]

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.

bug#7348: 23.2.50; Emacs crashes on fast window resize with scrollbars on under OSX

[Eli Zaretskii]

> 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)?

bug#7348: 23.2.50; Emacs crashes on fast window resize with scrollbars on under OSX

[Jan Djärv]

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.