GNU bug report logs - #18403
24.4.50; emacsclient sometimes hangs on exit with Lucid GUI client

Previous Next

Package: emacs;

Reported by: Christoph Scholtes <cschol2112 <at> gmail.com>

Date: Thu, 4 Sep 2014 03:06:02 UTC

Severity: normal

Tags: patch

Found in version 24.4.50

Done: Christoph <cschol2112 <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Christoph <cschol2112 <at> gmail.com>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#18403: closed (24.4.50; emacsclient sometimes hangs on exit
 with Lucid GUI client)
Date: Sat, 13 Sep 2014 16:22:02 +0000
[Message part 1 (text/plain, inline)]
Your message dated Sat, 13 Sep 2014 10:21:50 -0600
with message-id <CAOrdkqNkLCv0==fqLuCLs9g25Q4SH9xkHiXi0F2Ex2eTJJbrdQ <at> mail.gmail.com>
and subject line Re: bug#18403: 24.4.50; emacsclient sometimes hangs on exit with Lucid GUI client
has caused the debbugs.gnu.org bug report #18403,
regarding 24.4.50; emacsclient sometimes hangs on exit with Lucid GUI client
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
18403: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18403
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
From: Christoph Scholtes <cschol2112 <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.4.50; emacsclient sometimes hangs on exit with Lucid GUI client
Date: Wed, 03 Sep 2014 21:05:45 -0600
Emacs 24 (r117814) compiled with Lucid toolkit.

Steps to reproduce:

emacs --daemon -q
emacsclient -c
Exit GUI client with `C-x C-c' or evaluate `(kill-emacs)' in *scratch*.

Emacsclient will hang with `Waiting for Emacs...' at the shell prompt
and not exit. In case of `(kill-emacs)', it will kill the daemon
correctly, but emacsclient hangs.

I attached a debugger and Emacs seems to be stuck in the do..while loop around
line 1734 of `emacsclient.c'.

I tried same procedure with Emacs compiled with GTK3 and it works
correctly. emacsclient exits at the prompt upon executing either `C-x
C-c' or (kill-emacs).

emacsclient -t also works correctly and emacsclient exits after
executing `C-x C-c'.



In GNU Emacs 24.4.50.2 (x86_64-unknown-linux-gnu, X toolkit, Xaw scroll bars)
 of 2014-09-03 on marvin
Repository revision: 117814 eggert <at> cs.ucla.edu-20140904020246-9nko8pp4vqjsfdfy
Windowing system distributor `The X.Org Foundation', version 11.0.11103000
System Description:	Linux Mint 13 Maya

Configured using:
 `configure --with-x-toolkit=lucid'

Configured features:
XPM JPEG TIFF GIF PNG SOUND DBUS GCONF GSETTINGS NOTIFY LIBSELINUX
GNUTLS LIBXML2 FREETYPE XFT ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  eldoc-mode: t
  my-keys-minor-mode: t
  erc-list-mode: t
  erc-menu-mode: t
  erc-autojoin-mode: t
  erc-ring-mode: t
  erc-networks-mode: t
  erc-pcomplete-mode: t
  erc-track-mode: t
  erc-match-mode: t
  erc-button-mode: t
  erc-fill-mode: t
  erc-stamp-mode: t
  erc-netsplit-mode: t
  erc-irccontrols-mode: t
  erc-noncommands-mode: t
  erc-move-to-prompt-mode: t
  erc-readonly-mode: t
  show-smartparens-global-mode: t
  show-smartparens-mode: t
  smartparens-global-mode: t
  smartparens-strict-mode: t
  smartparens-mode: t
  shell-dirtrack-mode: t
  desktop-save-mode: t
  ido-everywhere: t
  global-auto-revert-mode: t
  tooltip-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  size-indication-mode: t
  column-number-mode: t
  line-number-mode: t

Recent input:
M-x r e p o r t - e m a c s - b u g <return>

Recent messages:
Desktop: 1 frame, 0 buffers restored.
Starting Emacs daemon.
Restarting server
Saving all Org-mode buffers...
(No files need saving)
Saving all Org-mode buffers... done
Saving all Org-mode buffers...
(No files need saving)
Saving all Org-mode buffers... done
When done with this frame, type C-x 5 0

[...]

Memory information:
((conses 16 287414 14434)
 (symbols 48 41994 0)
 (miscs 40 87 169)
 (strings 32 88161 8807)
 (string-bytes 1 2681717)
 (vectors 16 32629)
 (vector-slots 8 631672 6983)
 (floats 8 203 274)
 (intervals 56 319 0)
 (buffers 976 12)
 (heap 1024 29623 1082))


[Message part 3 (message/rfc822, inline)]
From: Christoph <cschol2112 <at> gmail.com>
To: 18403-done <at> debbugs.gnu.org
Cc: Paul Eggert <eggert <at> cs.ucla.edu>, Dmitry Antipov <dmantipov <at> yandex.ru>
Subject: Re: bug#18403: 24.4.50; emacsclient sometimes hangs on exit with
 Lucid GUI client
Date: Sat, 13 Sep 2014 10:21:50 -0600
[Message part 4 (text/plain, inline)]
The original issue of the hanging emacsclient with Lucid is fixed in trunk,
bzr r117565. I am closing this bug.

Thank you.

On Mon, Sep 8, 2014 at 3:33 PM, Christoph <cschol2112 <at> gmail.com> wrote:

> One other thing I noticed:
>
> after quitting the GUI frame, Ctrl-C to break the "waiting" loop and
> reconnecting with a terminal emacsclient, the *Messages* buffer shows the
> following error:
>
> server-delete-client: X protocol error: BadFont (invalid Font parameter)
> on protocol request 46
>
> Not sure if that helps at all.
>
> On Mon, Sep 8, 2014 at 8:18 AM, Dmitry Antipov <dmantipov <at> yandex.ru>
> wrote:
>
>> On 09/08/2014 05:44 PM, Paul Eggert wrote:
>>
>>  I cannot reproduce this new problem on Ubuntu 14.04, configuring trunk
>>> bzr 117843 --with-x-toolkit=lucid.
>>> x_delete_terminal calls XtCloseDisplay, and then calls emacs_close
>>> (dpyinfo->connection), and
>>> the 'close' returns 0.
>>>
>>> Perhaps you configured with some other toolkit?  That might explain the
>>> discrepancy.
>>>
>>
>> No, this is Lucid but with your revert patch applied.
>>
>>  Does it fix things for you if you add a line 'dpyinfo->connection = -1;'
>>> after the existing line
>>> 'dpyinfo->display = 0;' in xterm.c's x_connection_closed?  Though that
>>> might cause a file descriptor
>>> leak; I'm not fully following what's going on here, since I can't
>>> reproduce the new problem.
>>>
>>
>> No, because x_connection_closed is not called.
>>
>> There is another example of a debugging session, clearly showing
>> double-close problem:
>>
>> ;; 1) Run ./src/emacs -Q --daemon
>> ;; 2) Run ./lib-src/emacsclient -c
>> ;; 3) Attach gdb -p to daemon process
>>
>> (gdb) b close
>> Breakpoint 1 at 0x3290ce6c10: close. (4 locations)
>> (gdb) b x_connection_closed
>> Breakpoint 2 at 0x541d10: file ../../trunk/src/xterm.c, line 8425.
>> (gdb) b die
>> Breakpoint 3 at 0x5f6d05: file ../../trunk/src/alloc.c, line 7116.
>> (gdb) c
>> Continuing.
>>
>> ;; 4) C-x C-c in emacsclient frame
>>
>> Breakpoint 1, close () at ../sysdeps/unix/syscall-template.S:81
>> 81      T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)
>> (gdb) n
>> close () at ../sysdeps/unix/syscall-template.S:82
>> 82              ret
>> (gdb)
>> xcb_disconnect (c=0x13825e0) at xcb_conn.c:320
>> 320         pthread_mutex_destroy(&c->iolock);
>> (gdb) p c->fd                                                      ;; X
>> connection fd is 8
>> $1 = 8
>> (gdb) c
>> Continuing.
>>
>> Breakpoint 1, close () at ../sysdeps/unix/syscall-template.S:81
>> 81      T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)
>> (gdb) n
>> 83      T_PSEUDO_END (SYSCALL_SYMBOL)
>> (gdb)
>> posix_close (fd=8, flag=1) at ../../trunk/src/sysdep.c:2386        ;;
>> We're closing X connection fd again
>> 2386    }
>> (gdb) c
>>
>> Continuing.
>> Breakpoint 3, die (msg=0x717274 "errno != EBADF || fd < 0", file=0x7170e0
>> "../../trunk/src/sysdep.c", line=2408)
>>     at ../../trunk/src/alloc.c:7116
>> 7116      fprintf (stderr, "\r\n%s:%d: Emacs fatal error: assertion
>> failed: %s\r\n",
>> (gdb) bt 6
>> #0  0x00000000005f6d05 in die (msg=0x717274 "errno != EBADF || fd < 0",
>> file=0x7170e0 "../../trunk/src/sysdep.c", line=2408)
>>     at ../../trunk/src/alloc.c:7116
>> #1  0x0000000000598480 in emacs_close (fd=8) at
>> ../../trunk/src/sysdep.c:2408         ;; This is it
>> #2  0x000000000054784b in x_delete_terminal (terminal=0xfa0218) at
>> ../../trunk/src/xterm.c:11382
>> #3  0x000000000051f8b6 in Fdelete_terminal (terminal=..., force=...) at
>> ../../trunk/src/terminal.c:348
>> #4  0x00000000004290ba in delete_frame (frame=..., force=...) at
>> ../../trunk/src/frame.c:1691
>> #5  0x0000000000429630 in Fdelete_frame (frame=..., force=...) at
>> ../../trunk/src/frame.c:1801
>>
>> Dmitry
>>
>
>
[Message part 5 (text/html, inline)]

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

Previous Next


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