GNU bug report logs - #17691
24.3.91; crash closing remote frame

Previous Next

Package: emacs;

Reported by: Ken Raeburn <raeburn <at> permabit.com>

Date: Wed, 4 Jun 2014 17:10:02 UTC

Severity: important

Tags: moreinfo, patch

Found in version 24.3.91

Done: Paul Eggert <eggert <at> cs.ucla.edu>

Bug is archived. No further changes may be made.

Full log


Message #34 received at 17691 <at> debbugs.gnu.org (full text, mbox):

From: Ken Raeburn <raeburn <at> permabit.com>
To: Dmitry Antipov <dmantipov <at> yandex.ru>
Cc: Glenn Morris <rgm <at> gnu.org>, 17691 <17691 <at> debbugs.gnu.org>
Subject: Re: bug#17691: 24.3.91; crash closing remote frame
Date: Thu, 5 Jun 2014 17:09:49 -0400
[Message part 1 (text/plain, inline)]
Oh, sorry... I just noticed in gdb I'd used my one-liner command line, and
the one you asked me to run didn't use "-nw".

If I use the command line you suggested, when $DISPLAY is defined as :0, I
get one window, and briefly a second; XUnloadFont isn't hit, since I've
still got a window open on that display. But I assume closing the final
window as in my test was what you actually wanted...

Also, if I use the window manager to close the X window rather than
invoking delete-frame, the "display :0 does not exist" message doesn't
appear.

Ken


On Thu, Jun 5, 2014 at 3:47 PM, Ken Raeburn <raeburn <at> permabit.com> wrote:

> With my one-liner test, using your patch, I finish up with a terminal
> session (as expected) with an error message "Display :0 does not exist" in
> the minibuffer (not expected). In the *Messages* buffer, it's recorded as
> "get-device-terminal: Display :0 does not exist", though it didn't display
> that way initially in the minibuffer.
>
> I set a breakpoint on XUnloadFont as requested, and "font" doesn't appear
> to be a valid pointer; is it supposed to be a resource id maybe?
>
>
> On Thu, Jun 5, 2014 at 12:53 AM, Dmitry Antipov <dmantipov <at> yandex.ru>
> wrote:
>
>> On 06/05/2014 01:49 AM, Ken Raeburn wrote:
>>
>>  A simpler reproduction just worked for me:
>>>
>>> emacs -Q -nw
>>>
>>> in the scratch buffer, evaluate:
>>>
>>> (let ((f (make-frame-on-display ":0" '((font . "7x14")))))
>>>    (delete-frame f))
>>>
>>> That's killed my Emacs processes pretty reliably.
>>>
>>> Simpler still:
>>>
>>> $ emacs -Q -nw --eval '(let ((f (make-frame-on-display ":0" '"'"'((font
>>> . "7x14"))))) (delete-frame f))'
>>>
>>> The terminal window gets a frame, the X display gets a frame, the X
>>> frame goes away, and the terminal-mode Emacs crashes.
>>>
>>
>> Please try this against emacs-24 branch or 24.3.91 (this is a backported
>> hybrid of trunk commits 116927 and 117126). If that works for you, this
>> should be incorporated into emacs-24 and included into the next pretest.
>>
>> Dmitry
>>
>>
>
[Message part 2 (text/html, inline)]

This bug report was last modified 10 years and 345 days ago.

Previous Next


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