bug#17691: 24.3.91; crash closing remote frame

[Ken Raeburn]

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