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

Previous Next

Packages: emacs, w32;

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

Date: Tue, 26 Mar 2013 23:36:02 UTC

Severity: normal

Merged with 14205

Found in version 24.3.50

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

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
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:18:18 +0300
> Date: Mon, 15 Apr 2013 14:40:46 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> CC: drew.adams <at> oracle.com, Juanma Barranquero <lekktu <at> gmail.com>, 
>  14062 <at> 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.




This bug report was last modified 12 years and 11 days ago.

Previous Next


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