bug#14062: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 15 Apr 2013 14:40:46 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: drew.adams@oracle.com, Juanma Barranquero <lekktu@gmail.com>, 
>  14062@debbugs.gnu.org
> 
>  > If XBUFFER is indeed the problem, then this means that this snippet,
>  > around line 3115 of w32fns.c:
>  >
>  > 	  f = x_window_to_frame (dpyinfo, hwnd);
>  > 	  w = XWINDOW (FRAME_SELECTED_WINDOW (f));
>  >
>  > produces a non-leaf window in w.  Can a frame's selected window be
>  > non-leaf?
> 
> 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?

> 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 and
XBUFFER hits an assertion violation, what else can this window be
except non-leaf?

>  > Anyway, I added in trunk revision 112287 some more debugging code to
>  > point out which assertions are violated.  Let's see what that gets us.
> 
> But you also added some parentheses so now we might not be able to find
> out whether it was just due to badly written macros ;-)

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.