GNU bug report logs - #44151
trmap: remote gdb with ssh doesn't work

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 44151 in the body.
You can then email your comments to 44151 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: William Xu <william.xwl <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: trmap: remote gdb with ssh doesn't work
Date: Thu, 22 Oct 2020 21:01:26 +0200

Hi,

I tried to run the debug remote program with gdb via ssh. I followed the
instructions from the [[info:tramp#Remote processes][info:tramp#Remote processes]]:

,----
| 5.5.5 Running a debugger on a remote host
| -----------------------------------------
| 
| ‘gud.el’ provides a unified interface to symbolic debuggers (*note
| (emacs)Debuggers::).  TRAMP can run debug on remote hosts by calling
| ‘gdb’ with a remote file name:
| 
|      M-x gdb <RET>
|      Run gdb (like this): gdb -i=mi /ssh:host:~/myprog <RET>
`----

However, after the program to debug is read, it looks like there is some
error setting up gdb's inferior tty?

---------------------------------8<------------------------------------- 
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /home/wx/tmp/a.out...

Debugger entered--Lisp error: (wrong-type-argument "consp nil")
  signal(wrong-type-argument ("consp nil"))
  tramp-signal-hook-function(wrong-type-argument (consp nil))
  signal(wrong-type-argument (consp nil))
  tramp-sh-handle-make-process(:name "gdb-inferior" :buffer #<buffer limbo<3>> :command nil :stderr nil :noquery nil :file-handler t)
  apply(tramp-sh-handle-make-process (:name "gdb-inferior" :buffer #<buffer limbo<3>> :command nil :stderr nil :noquery nil :file-handler t))
  tramp-sh-file-name-handler(make-process :name "gdb-inferior" :buffer #<buffer limbo<3>> :command nil :stderr nil :noquery nil :file-handler t)
  apply(tramp-sh-file-name-handler make-process (:name "gdb-inferior" :buffer #<buffer limbo<3>> :command nil :stderr nil :noquery nil :file-handler t))
  tramp-file-name-handler(make-process :name "gdb-inferior" :buffer #<buffer limbo<3>> :command nil :stderr nil :noquery nil :file-handler t)
  tramp-handle-start-file-process("gdb-inferior" #<buffer limbo<3>> nil)
  apply(tramp-handle-start-file-process ("gdb-inferior" #<buffer limbo<3>> nil))
  tramp-sh-file-name-handler(start-file-process "gdb-inferior" #<buffer limbo<3>> nil)
  apply(tramp-sh-file-name-handler start-file-process ("gdb-inferior" #<buffer limbo<3>> nil))
  tramp-file-name-handler(start-file-process "gdb-inferior" #<buffer limbo<3>> nil)
  apply(tramp-file-name-handler start-file-process "gdb-inferior" #<buffer limbo<3>> nil nil)
  start-file-process("gdb-inferior" #<buffer limbo<3>> nil)
  apply(start-file-process "gdb-inferior" #<buffer limbo<3>> nil nil)
  comint-exec-1("gdb-inferior" #<buffer limbo<3>> nil nil)
  comint-exec(#<buffer limbo<3>> "gdb-inferior" nil nil nil)
  make-comint-in-buffer("gdb-inferior" #<buffer limbo<3>> nil)
  gdb-inferior-io-mode()
  gdb-get-buffer-create(gdb-inferior-io)
  gdb-init-1()
  gdb-update()
  gdb("gdb -i=mi /ssh:wx <at> SERVER:/home/wx/tmp...")
  funcall-interactively(gdb "gdb -i=mi /ssh:wx <at> SERVER:/home/wx/tmp...")
  call-interactively(gdb record nil)
  command-execute(gdb record)
  execute-extended-command(nil "gdb" nil)
  funcall-interactively(execute-extended-command nil "gdb" nil)
  call-interactively(execute-extended-command nil nil)
  command-execute(execute-extended-command)
---------------------------------8<------------------------------------- 

I tested it with `-Q' by building the latest emacs in the git:

GNU Emacs 28.0.50 (build 1, x86_64-apple-darwin18.7.0, NS appkit-1671.60 Version 10.14.6 (Build 18G6032)) of 2020-10-22

-- 
William

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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: William Xu <william.xwl <at> gmail.com>
Cc: 44151 <at> debbugs.gnu.org
Subject: Re: bug#44151: trmap: remote gdb with ssh doesn't work
Date: Fri, 23 Oct 2020 16:52:27 +0200

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

William Xu <william.xwl <at> gmail.com> writes:

> Hi,

Hi,

> However, after the program to debug is read, it looks like there is some
> error setting up gdb's inferior tty?
>
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from /home/wx/tmp/a.out...
>
> Debugger entered--Lisp error: (wrong-type-argument "consp nil")
>   signal(wrong-type-argument ("consp nil"))

Confirmed. Does the appended patch fixes the problem?

Best regards, Michael.

[Message part 2 (text/x-patch, attachment)]

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

From: William Xu <william.xwl <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#44151: trmap: remote gdb with ssh doesn't work
Date: Fri, 23 Oct 2020 18:49:01 +0200

Michael Albinus <michael.albinus <at> gmx.de> writes:

> Confirmed. Does the appended patch fixes the problem?

Thanks for the fast fix! Yes, now gdb can work.

However, I notice that after I set a breakpoint in the file, I could see
the red dot for the breakpoint in the buffer, but when I start to run
it, I don't see the debugger step marker in the file buffer, for
indicating the next line to follow. Is this expected behavior?

-- 
William

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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: William Xu <william.xwl <at> gmail.com>
Cc: 44151 <at> debbugs.gnu.org
Subject: Re: bug#44151: trmap: remote gdb with ssh doesn't work
Date: Sat, 24 Oct 2020 16:25:00 +0200

William Xu <william.xwl <at> gmail.com> writes:

Hi,

> Thanks for the fast fix! Yes, now gdb can work.

Thanks for the feedback. I've pushed the patch to the repo.

> However, I notice that after I set a breakpoint in the file, I could see
> the red dot for the breakpoint in the buffer, but when I start to run
> it, I don't see the debugger step marker in the file buffer, for
> indicating the next line to follow. Is this expected behavior?

No, I don't believe so. I could confirm this misbehaviour.

And I'm sorry, I don't know gdb-mi.el. Hopefully, somebody else could
fix this.

Best regards, Michael.

Previous Next

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