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

Previous Next

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, 14630 <at> debbugs.gnu.org
Subject: bug#14630: 24.3.50; emacs_backtrace.txt
Date: Wed, 19 Jun 2013 05:46:30 +0300

> X-Spam-Status: No, score=-99.2 required=5.0 tests=BAYES_50,FREEMAIL_FROM,
> 	RCVD_IN_DNSWL_NONE,USER_IN_WHITELIST autolearn=disabled version=3.3.2
> Date: Tue, 18 Jun 2013 21:31:58 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> CC: lekktu <at> gmail.com, 14630 <at> debbugs.gnu.org
> 
>  > The backtraces reported by Drew consistently point to this line in
>  > w32fns.c:
>  >
>  > 	    form.rcArea.top += WINDOW_HEADER_LINE_HEIGHT (w);
>  >
>  > i.e. to whatever happens in the expansion of
>  > WINDOW_HEADER_LINE_HEIGHT.
> 
> But quite a lot can happen in this expansion.  Can this fail in
> CURRENT_HEADER_LINE_HEIGHT?

That again either calls XFRAME or current_header_line_height, which
should have been seen in the backtrace.

> You mean FRAMEP?

Yes.

>  >> Maybe we should start replacing BUFFERP by BUFFER_LIVE_P.  BUFFERP (like
>  >> WINDOWP and FRAMEP) is IMHO harmful virtually everywhere.
>  >
>  > I didn't touch any BUFFERP or related macro in the last change.
> 
> I know.  I meant that instead of BUFFERP (w->contents) we could check
> BUFFER_LIVE_P (XBUFFER (w->contents)) there.

How's that related to the assertion that is violated?

Previous Next

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