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

Previous Next

Full log

View this message in rfc822 format

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: lekktu <at> gmail.com, 14062 <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: bug#14062: 24.3.50; emacs_backtrace.txt
Date: Mon, 15 Apr 2013 17:53:26 +0200

>> I could imagine lots of things including dead windows.
>
> Are these "things", including dead windows, allowed to be the selected
> window of a frame that gets input messages from Windows, i.e. is at
> least visible, if not in the foreground?

Hopefully never.  Non-leaf and deleted windows are only used by the
window management and the redisplay code (the latter could also employ a
simple list of live windows instead).  And deleted windows are only
allowed in saved window configurations.

Conceptually, the selected window must be always a leaf window.  During
a deletion this invariant might get temporarily violated until another
leaf window has been selected.  Maybe that's what we are hitting here.
An internal window is a priori never selected.

>> But it would be a strange coincidence if it were a non-leaf window.
>> What drives you to this question?
>
> Only a non-leaf window can have its w->contents be something other
> than a buffer, right?  If BUFFERP(w->contents) returns zero

... for an internal window w->contents _must_ be another window, only
for deleted windows this can be nil (but Dmitry would have to verify
this, I didn't look at his last changes yet) ...

> and
> XBUFFER hits an assertion violation, what else can this window be
> except non-leaf?

A window with an uninitialized contents field.  Such windows exist from
the moment they are allocated by make_window until they either get a
child or a buffer in the contents field.

> I don't think so.  I examined the preprocessed source, and didn't see
> any instance of missing parentheses.  I added some just so someone who
> looks at the macros won't wonder, like I did, whether this could be
> the problem.
>
> But even if you are right, and the problem will now disappear, we can
> still resolve this bug by simply going back to the original code.

I don't think the problem will disappear this way.

martin

Previous Next

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