GNU bug report logs - #13007
24.3.50; emacs_backtrace.txt

Previous Next

Package: emacs;

Reported by: "Drew Adams" <drew.adams <at> oracle.com>

Date: Tue, 27 Nov 2012 06:26:02 UTC

Severity: normal

Merged with 13012, 13020

Found in version 24.3.50

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Antipov <dmantipov <at> yandex.ru>
Cc: 13007 <at> debbugs.gnu.org, lekktu <at> gmail.com, drew.adams <at> oracle.com
Subject: Re: bug#13007: 24.3.50; emacs_backtrace.txt
Date: Wed, 28 Nov 2012 19:59:08 +0200
> Date: Wed, 28 Nov 2012 19:51:37 +0400
> From: Dmitry Antipov <dmantipov <at> yandex.ru>
> CC: Juanma Barranquero <lekktu <at> gmail.com>, 
>  Drew Adams <drew.adams <at> oracle.com>,
>  Eli Zaretskii <eliz <at> gnu.org>
> 
> OK. Your crash recipe from Bug#13012 (which I can reproduce) hits the
> corner case where XBUFFER (XWINDOW (selected_window)->buffer) !=
> current_buffer; this should be fixed by always examining window buffer
> instead of current.

The display engine assumes that the buffer being rendered is
current_buffer in a lot of places.  If you want to use w->buffer
instead, you will have to change many places, including those that
don't receive a pointer to the window being redisplayed.  (And there's
the TTY redisplay which is frame-based, and doesn't necessarily go by
windows in the first place.)

Let me turn the table and ask why should we insist on this assertion?
What do we gain by enforcing it?

I know what we lose: the trunk is severely broken for 2 days, and
counting.  3 people have independently bumped into this in 2 different
situations.  If there's no significant gain in this, I say let's
remove the assertion and move on.




This bug report was last modified 9 years and 199 days ago.

Previous Next


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