bug#24616: 26.0.50; No backtrace when emacsclient --eval fails

bug#24616: 26.0.50; No backtrace when emacsclient --eval fails

[Philipp Stephani]

Start the server.
Then run e.g.

$ emacsclient --eval '(progn (defun f () (error "foo")) (setq debug-on-error t) (f))'
*ERROR*: foo

Note that there's no backtrace. This makes it almost impossible to debug
problems when using emacsclient.


In GNU Emacs 26.0.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.10.8)
 of 2016-10-04 built on unknown
Repository revision: e2913dc880b9843bf69cf885270551bafeb46120
Windowing system distributor 'The X.Org Foundation', version 11.0.11501000
System Description:	Ubuntu 14.04 LTS

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Configured using:
 'configure --with-modules --enable-checking
 --enable-check-lisp-object-type'

Configured features:
XPM JPEG TIFF GIF PNG SOUND GSETTINGS NOTIFY GNUTLS FREETYPE XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 MODULES

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

Major mode: Lisp Interaction

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
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message subr-x puny seq byte-opt gv
bytecomp byte-compile cl-extra help-mode cconv cl-loaddefs pcase cl-lib
dired dired-loaddefs format-spec rfc822 mml easymenu mml-sec
password-cache epa derived epg epg-config gnus-util rmail rmail-loaddefs
mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils
mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr
mail-utils time-date mule-util tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel term/x-win 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 term/tty-colors 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 obarray 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 inotify dynamic-setting
system-font-setting font-render-setting move-toolbar gtk x-toolkit x
multi-tty make-network-process emacs)

Memory information:
((conses 16 97800 7962)
 (symbols 48 20400 0)
 (miscs 40 325 144)
 (strings 32 17966 4881)
 (string-bytes 1 589539)
 (vectors 16 13792)
 (vector-slots 8 454069 6477)
 (floats 8 183 13)
 (intervals 56 215 0)
 (buffers 976 12)
 (heap 1024 42234 1051))

-- 
Google Germany GmbH
Erika-Mann-Straße 33
80636 München

Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle

Diese E-Mail ist vertraulich.  Wenn Sie nicht der richtige Adressat sind,
leiten Sie diese bitte nicht weiter, informieren Sie den Absender und löschen
Sie die E-Mail und alle Anhänge.  Vielen Dank.

This e-mail is confidential.  If you are not the right addressee please do not
forward it, please inform the sender, and please erase this e-mail including
any attachments.  Thanks.

bug#24616: 26.0.50; No backtrace when emacsclient --eval fails

[Eli Zaretskii]

> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Tue, 04 Oct 2016 18:30:15 +0200
> 
> Start the server.
> Then run e.g.
> 
> $ emacsclient --eval '(progn (defun f () (error "foo")) (setq debug-on-error t) (f))'
> *ERROR*: foo
> 
> Note that there's no backtrace. This makes it almost impossible to debug
> problems when using emacsclient.

See this discussion:

  http://lists.gnu.org/archive/html/emacs-devel/2016-08/msg00122.html

bug#24616: 26.0.50; No backtrace when emacsclient --eval fails

[Noam Postavsky]

On Tue, Oct 4, 2016 at 12:30 PM, Philipp Stephani <p.stephani2@gmail.com> wrote:
>
> Start the server.
> Then run e.g.
>
> $ emacsclient --eval '(progn (defun f () (error "foo")) (setq debug-on-error t) (f))'
> *ERROR*: foo
>
> Note that there's no backtrace. This makes it almost impossible to debug
> problems when using emacsclient.
>

Just a note: you can get a backtrace by setting debug-on-signal
instead of debug-on-error.

bug#24616: 26.0.50; No backtrace when emacsclient --eval fails

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 697 bytes --]

On 2016-10-04 16:52, Noam Postavsky wrote:
> On Tue, Oct 4, 2016 at 12:30 PM, Philipp Stephani <p.stephani2@gmail.com> wrote:
>>
>> Start the server.
>> Then run e.g.
>>
>> $ emacsclient --eval '(progn (defun f () (error "foo")) (setq debug-on-error t) (f))'
>> *ERROR*: foo
>>
>> Note that there's no backtrace. This makes it almost impossible to debug
>> problems when using emacsclient.
>>
> 
> Just a note: you can get a backtrace by setting debug-on-signal
> instead of debug-on-error.

Really?

$ emacsclient --eval '(progn (defun f () (error "foo")) (setq debug-on-signal t debug-on-error t) (f))'
*ERROR*: foo

Am I missing something obvious?

Cheers,
Clément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

bug#24616: 26.0.50; No backtrace when emacsclient --eval fails

[Noam Postavsky]

On Tue, Oct 4, 2016 at 6:28 PM, Clément Pit--Claudel
<clement.pit@gmail.com> wrote:
> On 2016-10-04 16:52, Noam Postavsky wrote:
>> On Tue, Oct 4, 2016 at 12:30 PM, Philipp Stephani <p.stephani2@gmail.com> wrote:
>>>
>>> Start the server.
>>> Then run e.g.
>>>
>>> $ emacsclient --eval '(progn (defun f () (error "foo")) (setq debug-on-error t) (f))'
>>> *ERROR*: foo
>>>
>>> Note that there's no backtrace. This makes it almost impossible to debug
>>> problems when using emacsclient.
>>>
>>
>> Just a note: you can get a backtrace by setting debug-on-signal
>> instead of debug-on-error.
>
> Really?
>
> $ emacsclient --eval '(progn (defun f () (error "foo")) (setq debug-on-signal t debug-on-error t) (f))'
> *ERROR*: foo
>
> Am I missing something obvious?

The backtrace shows up in Emacs, where the server is running.

bug#24616: 26.0.50; No backtrace when emacsclient --eval fails

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 953 bytes --]

On 2016-10-04 19:50, Noam Postavsky wrote:
> On Tue, Oct 4, 2016 at 6:28 PM, Clément Pit--Claudel
> <clement.pit@gmail.com> wrote:
>> On 2016-10-04 16:52, Noam Postavsky wrote:
>>> On Tue, Oct 4, 2016 at 12:30 PM, Philipp Stephani <p.stephani2@gmail.com> wrote:
>>>>
>>>> Start the server.
>>>> Then run e.g.
>>>>
>>>> $ emacsclient --eval '(progn (defun f () (error "foo")) (setq debug-on-error t) (f))'
>>>> *ERROR*: foo
>>>>
>>>> Note that there's no backtrace. This makes it almost impossible to debug
>>>> problems when using emacsclient.
>>>>
>>>
>>> Just a note: you can get a backtrace by setting debug-on-signal
>>> instead of debug-on-error.
>>
>> Really?
>>
>> $ emacsclient --eval '(progn (defun f () (error "foo")) (setq debug-on-signal t debug-on-error t) (f))'
>> *ERROR*: foo
>>
>> Am I missing something obvious?
> 
> The backtrace shows up in Emacs, where the server is running.

Thanks for clarifying!


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

bug#24616: 26.0.50; No backtrace when emacsclient --eval fails

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@users.sourceforge.net>
> Date: Tue, 4 Oct 2016 19:50:23 -0400
> Cc: 24616@debbugs.gnu.org
> 
> >>> $ emacsclient --eval '(progn (defun f () (error "foo")) (setq debug-on-error t) (f))'
> >>> *ERROR*: foo
> >>>
> >>> Note that there's no backtrace. This makes it almost impossible to debug
> >>> problems when using emacsclient.
> >>>
> >>
> >> Just a note: you can get a backtrace by setting debug-on-signal
> >> instead of debug-on-error.
> >
> > Really?
> >
> > $ emacsclient --eval '(progn (defun f () (error "foo")) (setq debug-on-signal t debug-on-error t) (f))'
> > *ERROR*: foo
> >
> > Am I missing something obvious?
> 
> The backtrace shows up in Emacs, where the server is running.

How about adding this to debugging.texi?

bug#24616: 26.0.50; No backtrace when emacsclient --eval fails

[npostavs]

Eli Zaretskii <eliz@gnu.org> writes:
>> >> Just a note: you can get a backtrace by setting debug-on-signal
>> >> instead of debug-on-error.
>> >
>> > Really?
>> >
>> > $ emacsclient --eval '(progn (defun f () (error "foo")) (setq debug-on-signal t debug-on-error t) (f))'
>> > *ERROR*: foo
>> >
>> > Am I missing something obvious?
>> 
>> The backtrace shows up in Emacs, where the server is running.
>
> How about adding this to debugging.texi?

Something like this?

diff --git i/doc/lispref/debugging.texi w/doc/lispref/debugging.texi
index c88a2fa..bb3ced4 100644
--- i/doc/lispref/debugging.texi
+++ w/doc/lispref/debugging.texi
@@ -152,6 +152,11 @@ Error Debugging
 must still fulfill the criteria specified by @code{debug-on-error} and
 @code{debug-ignored-errors}.)
 
+For example, setting this variable is useful to get a backtrace from
+code evaluated by emacsclient.  If elisp code evaluated by emacsclient
+signals an error while this variable is non-@code{nil}, the backtrace
+will popup in the running Emacs.
+
 @strong{Warning:} Setting this variable to non-@code{nil} may have
 annoying effects.  Various parts of Emacs catch errors in the normal
 course of affairs, and you may not even realize that errors happen

bug#24616: 26.0.50; No backtrace when emacsclient --eval fails

[Eli Zaretskii]

> From: npostavs@users.sourceforge.net
> Cc: 24616@debbugs.gnu.org,  clement.pit@gmail.com
> Date: Sat, 22 Oct 2016 11:35:49 -0400
> 
> Something like this?
> 
> diff --git i/doc/lispref/debugging.texi w/doc/lispref/debugging.texi
> index c88a2fa..bb3ced4 100644
> --- i/doc/lispref/debugging.texi
> +++ w/doc/lispref/debugging.texi
> @@ -152,6 +152,11 @@ Error Debugging
>  must still fulfill the criteria specified by @code{debug-on-error} and
>  @code{debug-ignored-errors}.)
>  
> +For example, setting this variable is useful to get a backtrace from
> +code evaluated by emacsclient.  If elisp code evaluated by emacsclient
> +signals an error while this variable is non-@code{nil}, the backtrace
> +will popup in the running Emacs.
> +

Yes, but please mention "--eval", and add an index entry so that this
text would be easier to locate.  Something like this:

  @cindex emacsclient, getting a backtrace
  @cindex backtrace from emacsclient's @option{--eval}

Also, a nit: I don't think we use "elisp" in the manual, we say
"Lisp" instead.

Thanks.

bug#24616: 26.0.50; No backtrace when emacsclient --eval fails

[npostavs]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: npostavs@users.sourceforge.net
>> Cc: 24616@debbugs.gnu.org,  clement.pit@gmail.com
>> Date: Sat, 22 Oct 2016 11:35:49 -0400
>> 
>> Something like this?
>> 
>> diff --git i/doc/lispref/debugging.texi w/doc/lispref/debugging.texi
>> index c88a2fa..bb3ced4 100644
>> --- i/doc/lispref/debugging.texi
>> +++ w/doc/lispref/debugging.texi
>> @@ -152,6 +152,11 @@ Error Debugging
>>  must still fulfill the criteria specified by @code{debug-on-error} and
>>  @code{debug-ignored-errors}.)
>>  
>> +For example, setting this variable is useful to get a backtrace from
>> +code evaluated by emacsclient.  If elisp code evaluated by emacsclient
>> +signals an error while this variable is non-@code{nil}, the backtrace
>> +will popup in the running Emacs.
>> +
>
> Yes, but please mention "--eval", and add an index entry so that this
> text would be easier to locate.  Something like this:
>
>   @cindex emacsclient, getting a backtrace
>   @cindex backtrace from emacsclient's @option{--eval}
>
> Also, a nit: I don't think we use "elisp" in the manual, we say
> "Lisp" instead.
>
> Thanks.

Fixed and pushed as b2ba6307 "Explain how to debug emacsclient lisp
errors".

bug#24616: 26.0.50; No backtrace when emacsclient --eval fails

[Stefan Kangas]

npostavs@users.sourceforge.net writes:

> Fixed and pushed as b2ba6307 "Explain how to debug emacsclient lisp
> errors".

Is there anything more to do here, or can this bug report be closed?

If I don't hear back within a couple of weeks, I'll just go ahead and
close this bug.

Best regards,
Stefan Kangas

bug#24616: 26.0.50; No backtrace when emacsclient --eval fails

[Philipp Stephani]

Am Sa., 2. Nov. 2019 um 02:10 Uhr schrieb Stefan Kangas <stefan@marxist.se>:
>
> npostavs@users.sourceforge.net writes:
>
> > Fixed and pushed as b2ba6307 "Explain how to debug emacsclient lisp
> > errors".
>
> Is there anything more to do here, or can this bug report be closed?


Well, ideally the stacktrace would be printed on the terminal invoking
emacsclient to ease debugging.

bug#24616: 26.0.50; No backtrace when emacsclient --eval fails

[Stefan Kangas]

severity 24616 wishlist
thanks

Philipp Stephani <p.stephani2@gmail.com> writes:

> > Is there anything more to do here, or can this bug report be closed?
>
> Well, ideally the stacktrace would be printed on the terminal invoking
> emacsclient to ease debugging.

OK.  You're probably right in that it would make for a better user
experience in this case.

I'm not sure how easy or hard this would be to do, but as it stands I
think this is a feature request rather than a bug.  I'm therefore
changing the severity to wishlist.  Feel free to change the severity
back to "minor" if you disagree.

Best regards,
Stefan Kangas

bug#24616: 26.0.50; No backtrace when emacsclient --eval fails

[Live System User]

npostavs@users.sourceforge.net writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: npostavs@users.sourceforge.net
>>> Cc: 24616@debbugs.gnu.org,  clement.pit@gmail.com
>>> Date: Sat, 22 Oct 2016 11:35:49 -0400
>>> 
>>> Something like this?
>>> 
>>> diff --git i/doc/lispref/debugging.texi w/doc/lispref/debugging.texi
>>> index c88a2fa..bb3ced4 100644
>>> --- i/doc/lispref/debugging.texi
>>> +++ w/doc/lispref/debugging.texi
>>> @@ -152,6 +152,11 @@ Error Debugging
>>>  must still fulfill the criteria specified by @code{debug-on-error} and
>>>  @code{debug-ignored-errors}.)
>>>  
>>> +For example, setting this variable is useful to get a backtrace from
>>> +code evaluated by emacsclient.  If elisp code evaluated by emacsclient
>>> +signals an error while this variable is non-@code{nil}, the backtrace
>>> +will popup in the running Emacs.
>>> +
>>
>> Yes, but please mention "--eval", and add an index entry so that this
>> text would be easier to locate.  Something like this:
>>
>>   @cindex emacsclient, getting a backtrace
>>   @cindex backtrace from emacsclient's @option{--eval}
>>
>> Also, a nit: I don't think we use "elisp" in the manual, we say
>> "Lisp" instead.
>>
>> Thanks.
>
> Fixed and pushed as b2ba6307 "Explain how to debug emacsclient lisp
> errors".

  This example doesn't work for me with Emacs daemon and the default
  Emacs terminal:

0. emacs -Q --daemon
Warning: due to a long standing Gtk+ bug
http://bugzilla.gnome.org/show_bug.cgi?id=85715
Emacs might crash when run in daemon mode and the X11 connection is unexpectedly lost.
Using an Emacs configured with --with-x-toolkit=lucid does not have this problem.
Starting Emacs daemon.

1. emacsclient -n --eval '(progn (defun f () (error "foo")) (setq debug-on-signal t debug-on-error t) (f))'

  (Aside: Although the option "-n" was used, Emacs doesn't return to the
  command prompt.)


2. From another xterm, connect to the Emacs server in order to see the
   *backtrace* buffer that should have been created:

   emacsclient -n non-existant-file.txt

   You now see an Emacs in the default TTY-mode with the *backtrace* buffer
   displayed:

Debugger entered--Lisp error: (error "foo")
  signal(error ("foo"))
  error("foo")
  f()
  (progn (defun f nil (error "foo")) (setq debug-on-signal t debug-on-error t) $
  eval((progn (defun f nil (error "foo")) (setq debug-on-signal t debug-on-erro$
  server-eval-and-print("(progn (defun f () (error \"foo\")) (setq debug-on-sig$
  #[0 "\302\301\242\300\"\207" [#<process server <1>> ("(progn (defun f () (err$
  funcall(#[0 "\302\301\242\300\"\207" [#<process server <1>> ("(progn (defun f$
  mapc(funcall (#[0 "\302\301\242\300\"\207" [#<process server <1>> ("(progn (d$
  server-execute(#<process server <1>> nil t (#[0 "\302\301\242\300\"\207" [#<p$
  #[0 "r\310^N^K!q\210\305\242\203^X^@\311\305\242!\203^X^@\305\242\202^Z^@^N\f$
  server-execute-continuation(#<process server <1>>)
  server-process-filter(#<process server <1>> "-dir /home/liveuser/ -nowait -cu$


  However, when you press any keycords, like "C-x C-b" (list-buffers),
  nothing happens!

  You can't "C-x k" (kill-buffer) or "M-x" (execute-extended-command).

  The only thing you can do is kill Emacs from another terminal shell prompt.


  You can, of course, do all f these things if you use Emacs in GUI-mode
  (emacsclient -c ...) instead of its default TTY-mode.


  Thanks.

bug#24616: 26.0.50; No backtrace when emacsclient --eval fails

[Noam Postavsky]

On Sun, Oct 23, 2016 at 8:51 PM, Live System User <nyc4bos@aol.com> wrote:
>
>   This example doesn't work for me with Emacs daemon and the default
>   Emacs terminal:
>
> 0. emacs -Q --daemon
> Warning: due to a long standing Gtk+ bug
> http://bugzilla.gnome.org/show_bug.cgi?id=85715
> Emacs might crash when run in daemon mode and the X11 connection is unexpectedly lost.
> Using an Emacs configured with --with-x-toolkit=lucid does not have this problem.
> Starting Emacs daemon.
>
> 1. emacsclient -n --eval '(progn (defun f () (error "foo")) (setq debug-on-signal t debug-on-error t) (f))'
>
>   (Aside: Although the option "-n" was used, Emacs doesn't return to the
>   command prompt.)
>
>
> 2. From another xterm, connect to the Emacs server in order to see the
>    *backtrace* buffer that should have been created:
>
>    emacsclient -n non-existant-file.txt
>
>    You now see an Emacs in the default TTY-mode with the *backtrace* buffer
>    displayed:

Hmm, I just get an empty *backtrace* buffer in that case. If I start a
tty-mode client before making the error, the backtrace pops up as
expected with no problems though.