GNU bug report logs - #14062
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, 14062 <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: bug#14062: 24.3.50; emacs_backtrace.txt
Date: Mon, 15 Apr 2013 19:21:24 +0300

> Date: Mon, 15 Apr 2013 17:53:26 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> CC: drew.adams <at> oracle.com, lekktu <at> gmail.com, 14062 <at> debbugs.gnu.org
> 
>  > Only a non-leaf window can have its w->contents be something other
>  > than a buffer, right?  If BUFFERP(w->contents) returns zero
> 
> ... for an internal window w->contents _must_ be another window, only
> for deleted windows this can be nil (but Dmitry would have to verify
> this, I didn't look at his last changes yet) ...

But for nil, BUFFERP will return zero, and the code that uses XBUFFER
should not be called, IMO.

>  > and
>  > XBUFFER hits an assertion violation, what else can this window be
>  > except non-leaf?
> 
> A window with an uninitialized contents field.  Such windows exist from
> the moment they are allocated by make_window until they either get a
> child or a buffer in the contents field.

But the uninitialized contents field should be zero, no?  Again, it
should not pass the BUFFERP test.

So the mystery still stands.

>  > 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.
> 
> I don't think the problem will disappear this way.

Neither do I.

Previous Next

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