unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
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





  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).