GNU bug report logs - #7728
24.0.50; GDB backtrace from abort

Previous Next

Full log

View this message in rfc822 format

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Eli Zaretskii'" <eliz <at> gnu.org>
Cc: 7728 <at> debbugs.gnu.org, monnier <at> IRO.UMontreal.CA
Subject: bug#7728: 24.0.50; GDB backtrace from abort
Date: Wed, 12 Jan 2011 11:52:37 -0800

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.