bug#14062: 24.3.50; emacs_backtrace.txt

[martin rudalics <rudalics@gmx.at>]

 >> 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