bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: 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 <address@hidden>
> Cc: Jakub Turski <address@hidden>, address@hidden
> 
>  > 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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]