bug#7728: 24.0.50; GDB backtrace from abort

[Drew Adams]

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

As I said, I followed the _source_ code in the debugger.  And the source code
does not cause a crash.  The source code lets us know what _should_ be happening
here, not what is actually happening that provokes a crash.

I asked if you wanted me to instead add some calls to `message' and then
byte-compile.  Let me know if there is some such test you would like me to try.
You asked that I try the debugger to see what window was selected etc., so I did
that (with the source code). 

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

Why?  The only thing new to the mix is the new Emacs dev version.  The source
code and the byte-compiled code are the same as before.  The regression is not
realized using the source code.  It happens only with the new dev version when
it executes the byte code.  Why isn't that relevant?

> I'm inclined to think that it's some weird side effect of
> Edebug, or maybe something else.

You think _what_ is a weird effect of edebug?  (I used `debug-on-entry', not
edebug, BTW.)  With the debugger there was no crash.  So it certainly cannot be
some weird effect of the debugger that is causing the crash.

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

The question is why the current Emacs dev version crashes with the byte-compiled
code.  Nothing more.  It's not about some risk from the source code.  The code
works fine in all prior Emacs versions - both the byte code and the source code.
And the source code works fine even in this dev version.

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

Seems more like an inescapable conclusion, to me.  Substitute any other Emcs
version and presto: no problem.  Substitute the source code for the byte code
and presto: no problem.

> The offending code

What offending code?

What you see as offending code, if it was already in 21.1, did not present a
problem - it wasn't offending anyone.

> has been in Emacs since v21.1, so the problem is not new in any way.

Of course the problem is new.  It's a _regression_.  There is no such crash in
any prior Emacs version.  You and I have different views of what "the problem"
is, I guess.  For me, the problem is the crash.  That's new.

> It could be that it got exposed in the current development code
> due to some other unrelated change.

Unrelated or related - we don't know yet.  Either way, the problem (crash)
happens only with the new Emacs and the (new or old) byte code.

> 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 know nothing about that, so I'm sure you're right about that possibility.  I
really have nothing to say about what the fix should be.  If there was always a
latent bug and it never manifested itself before because of a lack of
ENABLE_CHECKING, then the final fix needs to be at least as good as the effect
of turning off ENABLE_CHECKING. ;-)

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

I did not understand that you have a solution.  I didn't get that impression
from your asking me to check the selected window in the debugger etc.  If you
have a solution, fantastic; that's good news.  I'm not trying to hurry you at
all.

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

In that case, we can have that discussion outside this bug thread, since you
recognize that it is separate and you apparently already have the solution for
the regression.

This is good news.  Thx.