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

Previous Next

Full log

Message #54 received at 14062 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#14062: 24.3.50; emacs_backtrace.txt
Date: Tue, 16 Apr 2013 09:08:06 +0300

> Date: Mon, 15 Apr 2013 21:22:00 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> CC: drew.adams <at> oracle.com, lekktu <at> gmail.com, 14062 <at> debbugs.gnu.org
> 
>  > But for nil, BUFFERP will return zero, and the code that uses XBUFFER
>  > should not be called, IMO.
> [...]
>  > But the uninitialized contents field should be zero, no?  Again, it
>  > should not pass the BUFFERP test.
>  >
>  > So the mystery still stands.
> 
> You mean that the w->contents argument of XBUFFER _always_ passes the
> BUFFERP test first and then fails at the assertion in XBUFFER?

Yes, see the definition of the WINDOW_WANTS_HEADER_LINE_P macro, where
we have:

     && BUFFERP (W->contents)					\
     && !NILP (BVAR (XBUFFER (W->contents), header_line_format))	\

Should a condition be always evaluated left to right?  Or is a
processor allowed to issue these two parts in parallel, if it has more
than one processing unit available?

> How can that make sense?

Exactly my question.  But the evidence is unequivocal: the assertion
in XBUFFER is the one that aborts.  I disassembled the code to make
sure I got that correctly.  This was an unoptimized build, so any
tricks with folding several different calls into one don't happen.

Previous Next

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