bug#7728: 24.0.50; GDB backtrace from abort

["Drew Adams" <drew.adams@oracle.com>]

> But I see that fit-frame uses save-window-excursion.  So it will call
> set-window-configuration after the form inside save-window-excursion
> is evaluated.
> 
> Can you see what window configuration is saved and restored there, and
> post that configuration here?

I loaded the source files fit-frame.el and oneonone.el and stepped through
`1on1-fit-minibuffer-frame'.

(Note: It does not crash when the source files are loaded, but you just wanted
to know what windows are involved etc.  The source-file debugging might not tell
us what the problem is with the byte-compiled file, however.  I could try
debugging with the latter, but typically the debugger doesn't show you much
then.  I could add calls to `message' instead of using the debugger, if you wish
- let me know.)

From the start the selected window and selected frame are already the minibuffer
window and minibuffer frame.  The `save-window-excursion' just moves to select
that window and frame (already selected), so the destination and the origin are
the same (`save-selected-window-window' is also the destination).  In this
context, the `save-window-excursion' should amount to a no-op.

I do not see any explicit window configs in the debugger - I see only window and
frame selection.  `save-window-excursion' just seems to save the selected window
and list of frames, and then restore them.

HTH.