bug#7728: 24.0.50; GDB backtrace from abort

[Eli Zaretskii]

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