Subject: bug#18403: closed (Re: bug#18403: 24.4.50; emacsclient sometimes hangs on exit with Lucid GUI client)

From: [email-masked] (GNU bug Tracking System)
Date: Sat, 13 Sep 2014 16:22:02 +0000

Your bug report

#18403: 24.4.50; emacsclient sometimes hangs on exit with Lucid GUI client

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
18403: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18403
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#18403: 24.4.50; emacsclient sometimes hangs on exit with Lucid GUI client
From: Christoph <[email-masked]>
To: [email-masked]
Cc: Paul Eggert <[email-masked]>, Dmitry Antipov <[email-masked]>
Date: Sat, 13 Sep 2014 10:21:50 -0600
List-Id: <debbugs-submit.debbugs.gnu.org>

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 <[email-masked]> 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 <[email-masked]>
> 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
>>
>
>

Subject: 24.4.50; emacsclient sometimes hangs on exit with Lucid GUI client
From: Christoph Scholtes <[email-masked]>
To: [email-masked]
Date: Wed, 03 Sep 2014 21:05:45 -0600
List-Id: <debbugs-submit.debbugs.gnu.org>

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 [email-masked]
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))