[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#14062: 24.3.50; emacs_backtrace.txt
From: |
martin rudalics |
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
- bug#14062: 24.3.50; emacs_backtrace.txt, Eli Zaretskii, 2013/04/15
- bug#14062: 24.3.50; emacs_backtrace.txt, Juanma Barranquero, 2013/04/15
- bug#14062: 24.3.50; emacs_backtrace.txt, martin rudalics, 2013/04/15
- bug#14062: 24.3.50; emacs_backtrace.txt, Eli Zaretskii, 2013/04/15
- bug#14062: 24.3.50; emacs_backtrace.txt,
martin rudalics <=
- bug#14062: 24.3.50; emacs_backtrace.txt, Eli Zaretskii, 2013/04/15
- bug#14062: 24.3.50; emacs_backtrace.txt, martin rudalics, 2013/04/15
- bug#14062: 24.3.50; emacs_backtrace.txt, Eli Zaretskii, 2013/04/16
- bug#14062: 24.3.50; emacs_backtrace.txt, Drew Adams, 2013/04/22
- bug#14062: 24.3.50; emacs_backtrace.txt, Juanma Barranquero, 2013/04/22
- bug#14062: 24.3.50; emacs_backtrace.txt, Eli Zaretskii, 2013/04/22
- bug#14062: 24.3.50; emacs_backtrace.txt, Drew Adams, 2013/04/22