GNU bug report logs -
#18403
24.4.50; emacsclient sometimes hangs on exit with Lucid GUI client
Previous Next
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
[Message part 1 (text/plain, inline)]
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 18403 <at> debbugs.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)]
[Message part 3 (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 4 (text/html, inline)]
[Message part 5 (message/rfc822, inline)]
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))
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.