[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#7728: 24.0.50; GDB backtrace from abort

From: Drew Adams
Subject: bug#7728: 24.0.50; GDB backtrace from abort
Date: Tue, 11 Jan 2011 20:59:52 -0800

> > > Perhaps Drew could publish the relevant parts of the window
> > > configuration that was being restored in that case (or any other
> > > similar case).
> > 
> > Sorry, I don't follow this at all at the C level, and even 
> > at the Lisp level I'm not sure I can be much help here.
> I think you can.  This is about the crash you originally posted in
> this bug, the one that happened because some window configuration was
> being restored.

(C'est toi qui le dis. ;-))  I don't think I was restoring any window config,
but something might have been doing so.

> Here's the Lisp backtrace you posted:
>   "fit-frame" (0x83ea54)
>   "1on1-fit-minibuffer-frame" (0x83ed70)
>   "run-hooks" (0x83ee3c)
>   "old-read-from-minibuffer" (0x83f404)
>   "read-from-minibuffer" (0x83f620)
>   "list" (0x83f85c)
>   "call-interactively" (0x83fb64)
> You also said back then:
> > `fit-frame' is one of my commands. It fits a frame to its (typically
> > sole) buffer. In this case, it was run on a hook, and it was the
> > standalone minibuffer frame that was being fit.
> >  
> > The hook was no doubt from a run-hooks called in or just 
> > after (vanilla) `read-from-minibuffer' (which is written
> > in C - I don't have the recent source code).
> I'm guessing that somewhere inside fit-frame you have code that
> restores configuration of windows that was previously saved.  I was
> asking for showing the relevant parts of that saved configuration,
> that would perhaps explain why set-window-configuration needs to
> select a different frame.

No, `fit-frame' does not restore any window config (unless Emacs does something
like that under the covers somehow), and it does not save any window config.  It
simply calculates the size of the buffer in terms of width and height, and
changes the frame width and height to fit it.  The code is here:

And `1on1-fit-minibuffer-frame' is here:

The call to `fit-frame' in `1on1-fit-minibuffer-frame' is this:
(fit-frame frame (frame-width frame))
where frame is the standalone minibuffer frame.

> > In the last GDB backtrace I sent (yesterday), I did the 
> > following, in my version of Emacs, in Icicle mode:
> > 
> > C-h f  g r a p h i c  S-TAB
> > 
> > Then click `mouse-2' on completion candidate `display-graphic-p'.
> > That should end completion and show *Help* (in a separate frame,
> > in my setup) with the output of `describe-function'.  Instead,
> > Emacs crashes (or whatever you call it - no error raised).
> > 
> > That crash (or whatever it is) is reproducible in my setup.
> This crash is identical to the first one.  So if you can show the
> window configuration data structure used by set-window-configuration
> in this case, it would be helpful.  TIA

I do not use `set-window-configuration' in my code at all.  I don't do anything
to or with window configurations in any of my code.

Here's some more info that might (or might not) help, though:

Since the latest crash is easily reproducible, I loaded fit-frame.el (not .elc)
and found that I could _not_ reproduce it - no crash.  IOW, when I load the
byte-compiled file Emacs crashes, but with the source file it does not crash.

What's more, I typically byte-compile in Emacs 20 (unless the library in
question requires a later version). But I've tested this with fit-frame.el that
was compiled using Emacs 20 and using the latest Emacs 24 Windows binary.
Either fit-frame.elc provokes the crash (in Emacs 24 only).

So something in the byte-compiled file leads to the "crash", whereas no error is
raised and no crash occurs if I load fit-frame.el.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]