GNU bug report logs - #26310
25.1; Emacsclient to emacs --daemon frame/connection error

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 26310 in the body.
You can then email your comments to 26310 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Live System User <nyc4bos <at> aol.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 25.1; Emacsclient to emacs --daemon frame/connection error
Date: Thu, 30 Mar 2017 10:31:12 -0400

Hi,

        I currently have an Emacs daemon that wont popup a new
        emacsclient frame initially using the emacsclient binary.

        Executing from the command line:

             emacsclient -c file.txt

        displays a quick momentary frame that disappears and shows
        on the command line:

           $ emacsclient -c file.txt
           emacsclient: can't find socket; have you started the server?
           To start the server in Emacs, type "M-x server-start".
           Waiting for Emacs...
           *ERROR*: Wrong type argument: stringp, nil
           $ 


        To try to track down why this was happening I "spoke" the
        Emacs server protocol to the Emacs daemon, created a GUI
        frame and enabled "debug-on-error" and server logging.

        Trying to connect again using "emacsclient -c", I see again
        a momentary newly-created frame that quickly disappears and
        I see in the " *server*" buffer (from my previously-created
        frame of the Daemon):

Thu Mar 30 06:43:33 2017 server <127.0.0.1:44966>: Status changed to open: open from 127.0.0.1
Thu Mar 30 06:43:33 2017 server <127.0.0.1:44966>: server-delete-client
Thu Mar 30 06:43:33 2017 server <127.0.0.1:44966>: Received -auth
<ommitted> -env TERM=xterm-256color [...] -dir /home/liveuser/ -display :0 -tty /dev/pts/1 xterm-256color -window-system -file file.txt 
Thu Mar 30 06:43:33 2017 server <127.0.0.1:44966>: Authentication successful
Thu Mar 30 06:43:33 2017 server <127.0.0.1:44966>: Sent -emacs-pid 10797
Thu Mar 30 06:43:33 2017 server <127.0.0.1:44966>: New file: /home/liveuser/file.txt 
Thu Mar 30 06:43:33 2017 server <127.0.0.1:44966>: #<frame emacs <at> localhost.localdomain 0x710d2e8> created
Thu Mar 30 06:43:33 2017 server <127.0.0.1:44966>: Sent -error Wrong&_type&_argument:&_stringp,&_nil
Thu Mar 30 06:43:33 2017 server <127.0.0.1:44966>: Wrong type argument: stringp, nil
Thu Mar 30 06:43:33 2017 server <127.0.0.1:44966>: Status changed to closed: connection broken by remote peer
Thu Mar 30 06:43:33 2017 server <127.0.0.1:44966>: server-delete-client
Thu Mar 30 06:43:33 2017 server <127.0.0.1:44966>: Deleted

    There's nothing new in the *Messages* buffer except:
    
        Debug on Error enabled globally

    Executing "emacsclient -t" yields the same error results.


    Strangely enough, although I get the same error message on the
    command line and very similar error messages in the " *server*"
    buffer:
    
Thu Mar 30 08:36:39 2017 server <127.0.0.1:45582>: New file: /home/liveuser/file.txt 
Thu Mar 30 08:36:39 2017 server <127.0.0.1:45582>: #<frame emacs <at> localhost.localdomain 0x3a83450> created
Thu Mar 30 08:36:39 2017 server <127.0.0.1:45582>: Sent -error Wrong&_type&_argument:&_stringp,&_nil
Thu Mar 30 08:36:39 2017 server <127.0.0.1:45582>: Wrong type argument: stringp, nil
Thu Mar 30 08:36:39 2017 server <127.0.0.1:45582>: Status changed to closed: connection broken by remote peer
Thu Mar 30 08:36:39 2017 server <127.0.0.1:45582>: server-delete-client
Thu Mar 30 08:36:39 2017 server <127.0.0.1:45582>: Deleted


    it DOES popup a new frame if I execute "emacsclient -nc file.txt"
    that doesn't disappear -- although it DOES NOT CREATE the file.txt
    buffer/window -- a new frame is created just as if I executed
    "C-x 5 2" `(make-frame-command)'.

    So a couple of questions this raise for me:
    
    What is different about using "--no-wait" with emacsclient that
    one is able to get past invocation errors (and at least get a
    new frame) that you can't get without "--no-wait"?

    What is the cause of the "stringp" error and why doesn't
    "debug-on-error" give further diagnostics on its cause?
    The " *server*" buffer logging information appears to show
    the correct passing of the protocol parameters so what is
    the argument(s) that the Emacs server belives is nil or
    missing?

    Although the new frame popped up (ONLY when using "--no-wait"),
    why didn't the specified buffer/window  get created?

    This just started happening about 4 hours ago although my
    "emacs --daemon" has been up for 3 days with frequent use
    in that timespan.
    
    How cam I track these errors down?

    I can leave the Emacs daemon up for a while.

    Thanks.




In GNU Emacs 25.1.1 (x86_64-redhat-linux-gnu, GTK+ Version 3.20.9)
 of 2016-10-13 built on buildvm-05.phx2.fedoraproject.org
Windowing system distributor 'Fedora Project', version 11.0.11803000
Configured using:
 'configure --build=x86_64-redhat-linux-gnu
 --host=x86_64-redhat-linux-gnu --program-prefix=
 --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr
 --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc
 --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64
 --libexecdir=/usr/libexec --localstatedir=/var
 --sharedstatedir=/var/lib --mandir=/usr/share/man
 --infodir=/usr/share/info --with-dbus --with-gif --with-jpeg --with-png
 --with-rsvg --with-tiff --with-xft --with-xpm --with-x-toolkit=gtk3
 --with-gpm=no --with-xwidgets build_alias=x86_64-redhat-linux-gnu
 host_alias=x86_64-redhat-linux-gnu 'CFLAGS=-DMAIL_USE_LOCKF -O2 -g
 -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4
 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
 -m64 -mtune=generic' LDFLAGS=-Wl,-z,relro
 PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig'

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND DBUS GCONF GSETTINGS NOTIFY
ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 XWIDGETS

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Summary

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
nnimap read 105k from imap.aim.com
nnimap read 113k from imap.aim.com
nnimap read 128k from imap.aim.com
Fetching headers for nnimap+aol:INBOX...done
Scoring...done
Sorting threads...done
Generating summary...done
Auto-saving...done
previous-line: Beginning of buffer
Making completion list...

Load-path shadows:
None found.

Features:
(shr-color color shr dom subr-x browse-url gnus-dup mailalias smtpmail
apropos thingatpt pp shadow emacsbug sendmail sort gnus-cite smiley
ansi-color mail-extr gnus-async gnus-bcklg qp gnus-ml disp-table
cursor-sensor nndraft nnmh mm-archive jka-compr timezone url-http url-gw
url-cache url-auth url-handlers utf-7 rfc2104 nnfolder nnagent nnml
network-stream nsm starttls gnus-agent gnus-srvr gnus-score score-mode
nnvirtual gnus-msg nntp gnus-cache epa-file epa derived nnreddit mm-url
url url-proxy url-privacy url-expand url-methods url-history url-cookie
url-domsuf url-util url-parse auth-source cl-seq eieio eieio-core
cl-macs url-vars json map seq byte-opt bytecomp byte-compile cl-extra
cconv gnus-art mm-uu mml2015 mm-view mml-smime smime dig mailcap cl gv
sieve sieve-mode sieve-manage nnir gnus-sum gnus-group gnus-undo
gnus-start gnus-cloud nnimap nnmail mail-source tls gnutls utf7 netrc
parse-time gnus-spec gnus-int gnus-range message dired format-spec
rfc822 mml mml-sec password-cache epg epg-config mm-decode mm-bodies
mm-encode mail-parse rfc2231 rfc2047 rfc2045 ietf-drums mailabbrev
gmm-utils mailheader gnus-win gnus gnus-ems wid-edit nnoo nnheader
gnus-util mm-util help-fns help-mode easymenu cl-loaddefs pcase cl-lib
mail-prsvr mail-utils time-date mule-util tooltip eldoc electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list newcomment elisp-mode lisp-mode prog-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core frame cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese charscript case-table epa-hook jka-cmpr-hook help
simple abbrev minibuffer cl-preloaded nadvice loaddefs button faces
cus-face macroexp files text-properties overlay sha1 md5 base64 format
env code-pages mule custom widget hashtable-print-readable backquote
dbusbind inotify dynamic-setting system-font-setting font-render-setting
xwidget-internal move-toolbar gtk x-toolkit x multi-tty
make-network-process emacs)

Memory information:
((conses 16 29211754 184124)
 (symbols 48 32156 42)
 (miscs 40 259 831)
 (strings 32 60692 34416)
 (string-bytes 1 1913637)
 (vectors 16 28888)
 (vector-slots 8 890936 133424)
 (floats 8 577 933)
 (intervals 56 5300 1106)
 (buffers 976 55)
 (heap 1024 571864 23349))

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

From: npostavs <at> users.sourceforge.net
To: Live System User <nyc4bos <at> aol.com>
Cc: 26310 <at> debbugs.gnu.org
Subject: Re: bug#26310: 25.1;
 Emacsclient to emacs --daemon frame/connection error
Date: Thu, 30 Mar 2017 21:26:23 -0400

Live System User <nyc4bos <at> aol.com> writes:

>     What is the cause of the "stringp" error and why doesn't
>     "debug-on-error" give further diagnostics on its cause?
>     The " *server*" buffer logging information appears to show
>     the correct passing of the protocol parameters so what is
>     the argument(s) that the Emacs server belives is nil or
>     missing?

The error happens inside a condition-case, so the debugger is not
invoked.  Can you try setting debug-on-signal?

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

From: Live System User <nyc4bos <at> aol.com>
To: npostavs <at> users.sourceforge.net
Cc: 26310 <at> debbugs.gnu.org
Subject: Re: bug#26310: 25.1;
 Emacsclient to emacs --daemon frame/connection error
Date: Fri, 31 Mar 2017 03:51:11 -0400

[Message part 1 (text/plain, inline)]

npostavs <at> users.sourceforge.net writes:

> Live System User <nyc4bos <at> aol.com> writes:
>
>>     What is the cause of the "stringp" error and why doesn't
>>     "debug-on-error" give further diagnostics on its cause?
>>     The " *server*" buffer logging information appears to show
>>     the correct passing of the protocol parameters so what is
>>     the argument(s) that the Emacs server belives is nil or
>>     missing?
>
> The error happens inside a condition-case, so the debugger is not
> invoked.  Can you try setting debug-on-signal?

  Here is the backtrace, as an attachment.

  Thanks.

[em-signal-error.txt (text/plain, attachment)]

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

From: npostavs <at> users.sourceforge.net
To: Live System User <nyc4bos <at> aol.com>
Cc: 26310 <at> debbugs.gnu.org
Subject: Re: bug#26310: 25.1;
 Emacsclient to emacs --daemon frame/connection error
Date: Fri, 31 Mar 2017 23:50:14 -0400

Live System User <nyc4bos <at> aol.com> writes:
>
> Debugger entered--Lisp error: (wrong-type-argument stringp nil)
>   isearch-done(t)
>   isearch-cancel()

Ah, that one.  This should be fixed already in 25.2, since #21091
"`isearch-done' called before `isearch-update' raises wrong-type-arg
error" was fixed.

Do you happen to know how you got into this state though?  That
isearch-cancel is being called at all might be a bug in itself, although
I never found out how to reproduce it...

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

From: uLive System User <nyc4bos <at> aol.com>
To: npostavs <at> users.sourceforge.net
Cc: 26310 <at> debbugs.gnu.org
Subject: Re: bug#26310: 25.1;
 Emacsclient to emacs --daemon frame/connection error
Date: Fri, 14 Apr 2017 23:24:56 -0400

npostavs <at> users.sourceforge.net writes:

> Live System User <nyc4bos <at> aol.com> writes:
>>
>> Debugger entered--Lisp error: (wrong-type-argument stringp nil)
>>   isearch-done(t)
>>   isearch-cancel()
>
> Ah, that one.  This should be fixed already in 25.2, since #21091
> "`isearch-done' called before `isearch-update' raises wrong-type-arg
> error" was fixed.

  I eval'ed your patched version of isearch.el into my Emacs daemon
  and "emacsclient <file>" started working again, so thank you for
  the fix.
  
>
> Do you happen to know how you got into this state though?  That
> isearch-cancel is being called at all might be a bug in itself, although
> I never found out how to reproduce it...

  I don't recall what I was doing specifically.  I keep a long-running
  Emacs daemon around and use emacsclient to connect to it regularly
  to edit files and update my Gnu ELPA packages.

 Thanks.
 

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

From: npostavs <at> users.sourceforge.net
To: uLive System User <nyc4bos <at> aol.com>
Cc: 26310 <at> debbugs.gnu.org
Subject: Re: bug#26310: 25.1;
 Emacsclient to emacs --daemon frame/connection error
Date: Sat, 15 Apr 2017 10:29:34 -0400

tags 26310 fixed
close 26310 25.2
quit

uLive System User <nyc4bos <at> aol.com> writes:

> npostavs <at> users.sourceforge.net writes:
>
>> Live System User <nyc4bos <at> aol.com> writes:
>>>
>>> Debugger entered--Lisp error: (wrong-type-argument stringp nil)
>>>   isearch-done(t)
>>>   isearch-cancel()
>>
>> Ah, that one.  This should be fixed already in 25.2, since #21091
>> "`isearch-done' called before `isearch-update' raises wrong-type-arg
>> error" was fixed.
>
>   I eval'ed your patched version of isearch.el into my Emacs daemon
>   and "emacsclient <file>" started working again, so thank you for
>   the fix.

Thanks for confirming.
   
>>
>> Do you happen to know how you got into this state though?  That
>> isearch-cancel is being called at all might be a bug in itself, although
>> I never found out how to reproduce it...
>
>   I don't recall what I was doing specifically.  I keep a long-running
>   Emacs daemon around and use emacsclient to connect to it regularly
>   to edit files and update my Gnu ELPA packages.

Yeah, the problem is that you wouldn't notice the state change
immediately, makes it pretty much impossible to catch this...

Previous Next

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