[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#14062: 24.3.50; emacs_backtrace.txt
From: |
Eli Zaretskii |
Subject: |
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@gmx.at>
> CC: drew.adams@oracle.com, lekktu@gmail.com, 14062@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.
- 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, 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, 2013/04/15
- bug#14062: 24.3.50; emacs_backtrace.txt,
Eli Zaretskii <=
- 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