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

Previous Next

Full log

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.

Previous Next

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