From: martin rudalics <rudalics@gmx.at>
To: Chong Yidong <cyd@gnu.org>
Cc: Russell Sim <russell.sim@gmail.com>, 11984@debbugs.gnu.org
Subject: bug#11984: 24.1; segfault while deleting a window
Date: Sat, 21 Jul 2012 13:03:24 +0200 [thread overview]
Message-ID: <500A8C7C.8000902@gmx.at> (raw)
In-Reply-To: <87fw8l7i3i.fsf@gnu.org>
>>> But for long-term safety, I think
>>> decode_any_windows had better signal an error if the window's frame
>>> isn't live. But I'm not sure if there's any subtle reliance in existing
>>> code on allowing window functions to be called for windows on dead
>>> frames---anyone know?
>> Maybe the best way to find out is to install such a change?
>
> Done in the trunk.
I must admit that I never looked at the definition of decode_any_window.
I always assumed that it _does_ check whether the window either has a
buffer or is in a window tree. So I think behavior is still broken
because a window can have been deleted while its frame is still alive.
IMHO the right fix is to throw an error for
if (NILP (w->buffer) && NILP (w->hchild) && NILP (w->vchild))
which means that some functions when called on dead windows (like
`delete-window') will now throw an error. These will have to be caught
on the Elisp level.
martin
next prev parent reply other threads:[~2012-07-21 11:03 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-18 22:08 bug#11984: 24.1; segfault while deleting a window Russell Sim
2012-07-19 3:05 ` Eli Zaretskii
2012-07-19 3:39 ` Chong Yidong
2012-07-19 10:41 ` martin rudalics
2012-07-21 6:18 ` Chong Yidong
2012-07-21 11:03 ` martin rudalics [this message]
2012-07-24 12:46 ` martin rudalics
2012-07-24 16:36 ` Eli Zaretskii
2012-07-25 7:15 ` martin rudalics
2012-07-25 15:27 ` Eli Zaretskii
2012-07-26 9:43 ` martin rudalics
2012-07-26 13:58 ` martin rudalics
2012-08-14 9:09 ` martin rudalics
2012-07-20 23:44 ` Russell Sim
2012-07-21 0:12 ` Russell Sim
2012-07-21 6:31 ` Chong Yidong
2012-07-21 9:00 ` Russell Sim
2012-07-21 9:32 ` Eli Zaretskii
2012-07-21 9:45 ` Russell Sim
2012-07-21 12:04 ` Eli Zaretskii
2012-07-21 8:02 ` Eli Zaretskii
2012-07-21 9:08 ` Russell Sim
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=500A8C7C.8000902@gmx.at \
--to=rudalics@gmx.at \
--cc=11984@debbugs.gnu.org \
--cc=cyd@gnu.org \
--cc=russell.sim@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).