From: Eli Zaretskii <eliz@gnu.org>
To: "Drew Adams" <drew.adams@oracle.com>
Cc: 7728@debbugs.gnu.org
Subject: bug#7728: 24.0.50; GDB backtrace from abort
Date: Thu, 13 Jan 2011 19:26:46 -0500 [thread overview]
Message-ID: <E1PdXV8-0003VI-Sm@fencepost.gnu.org> (raw)
In-Reply-To: <B32C9B7054D74650AE29DE3EE44B8E7F@us.oracle.com> (drew.adams@oracle.com)
> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: "'Eli Zaretskii'" <eliz@gnu.org>, <7728@debbugs.gnu.org>
> Date: Thu, 13 Jan 2011 09:57:11 -0800
>
> In this case the `save-window-excursion' should amount to a no-op in the end.
> The source and target window and frame need not be the same in general, but they
> are the same in the crashes I reported.
I don't believe this to be true, at least not from Emacs's internals
POV. The code that crashes clearly executes the branch where the
frame recorded by save-window-excursion is NOT the selected frame by
the time the body of save-window-excursion is done being evaluated.
> * Let me repeat that the _source code works fine_ - no error, no crash, no bug.
>
> * Let me repeat too that the byte-compiled code (no matter which Emacs version
> it was compiled with) works fine in all Emacs versions except the current
> development code - no error, no crash, no bug.
I don't think this to be relevant, sorry. I'm inclined to think that
it's some weird side effect of Edebug, or maybe something else. The
C backtrace is very clear and there's no ambiguity whatsoever in
interpreting it: when save-window-excursion involves switching frames,
the restoration of the original window configuration runs a high risk
to hit this bug, especially when many standard buffers (minibuffer,
*Help*, "Completions*", etc.) use separate frames.
> This is a _regression_ due to some change in the development version that no
> longer plays well with the byte-compiled code.
That's a possibility, but I think it's a remote one. The offending
code has been in Emacs since v21.1, so the problem is not new in any
way. It could be that it got exposed in the current development code
due to some other unrelated change. It could also be that this is the
first time you are running a binary that was built with
ENABLE_CHECKING defined: without that, the abort won't happen at all.
I think you interpret the latest messages incorrectly. No one is
arguing that your code is the culprit. The correct way to fix this
bug was pointed out by Stefan several messages ago, and I will do just
that when I have time. The latest discussions were generally about
the wisdom of switching frames inside save-window-excursion, and
whether we should do something about its problematic semantics, that's
all.
next prev parent reply other threads:[~2011-01-14 0:26 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-24 16:55 bug#7728: 24.0.50; GDB backtrace from abort Drew Adams
2010-12-25 9:38 ` Eli Zaretskii
2010-12-25 10:44 ` Andreas Schwab
2010-12-25 11:12 ` Eli Zaretskii
2010-12-25 20:35 ` Stefan Monnier
2011-01-01 18:02 ` Eli Zaretskii
2011-01-09 21:18 ` Eli Zaretskii
2011-01-10 23:32 ` Drew Adams
2011-01-11 20:55 ` Stefan Monnier
2011-01-11 21:14 ` Eli Zaretskii
2011-01-11 21:44 ` Drew Adams
2011-01-12 4:11 ` Eli Zaretskii
2011-01-12 4:59 ` Drew Adams
2011-01-12 11:03 ` Eli Zaretskii
2011-01-12 18:36 ` Drew Adams
2011-01-12 19:52 ` Drew Adams
2011-01-12 21:30 ` Drew Adams
2011-01-12 7:54 ` martin rudalics
2011-01-12 15:05 ` Drew Adams
2011-01-12 15:14 ` Stefan Monnier
2011-01-12 15:59 ` martin rudalics
2011-01-12 16:22 ` Eli Zaretskii
2011-01-12 17:42 ` martin rudalics
2011-01-12 17:48 ` Eli Zaretskii
2011-01-12 18:35 ` martin rudalics
2011-01-12 18:36 ` Drew Adams
2011-01-15 2:59 ` Chong Yidong
2011-01-15 20:05 ` martin rudalics
2011-01-13 2:53 ` Stefan Monnier
2011-01-13 7:07 ` Drew Adams
2011-01-13 17:02 ` Stefan Monnier
2011-01-13 17:57 ` Drew Adams
2011-01-13 21:24 ` Stefan Monnier
2011-01-13 22:06 ` Drew Adams
2011-01-14 0:26 ` Eli Zaretskii [this message]
2011-01-14 1:19 ` Drew Adams
2011-01-14 2:40 ` Eli Zaretskii
2011-01-14 6:46 ` Drew Adams
2011-01-14 7:09 ` Drew Adams
2011-01-14 20:01 ` Sean Sieger
2011-01-14 21:06 ` Drew Adams
2011-01-14 21:46 ` Sean Sieger
2011-01-14 22:51 ` Eli Zaretskii
2011-01-14 23:56 ` Sean Sieger
2011-01-14 2:25 ` Stefan Monnier
2011-01-14 4:25 ` Drew Adams
2011-01-14 8:26 ` martin rudalics
2011-01-14 8:58 ` Drew Adams
2011-01-14 15:30 ` Stefan Monnier
2011-01-16 20:44 ` Drew Adams
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=E1PdXV8-0003VI-Sm@fencepost.gnu.org \
--to=eliz@gnu.org \
--cc=7728@debbugs.gnu.org \
--cc=drew.adams@oracle.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).