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

Previous Next

Full log

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

Previous Next

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