I am running into an issue where the gdb command fails over tramp. The remote host is a simple linux box I am accessing via ssh. Even when I run emacs without my init file it still happens.
- Emacs 27.1
- Tramp 2.4.3.27.1
- gdb (on remote host) 8.0
- Mac OS Catalina 10.15.7 (local host OS)
I am running M-x gdb on a remote buffer, which results in the prompt: Run gdb (like this): gdb -i=mi. (Note that I am just trying to run gdb as a bare executable.) After hitting enter, I get an error in the minibuffer: wrong-type-argument "consp nil" and the resulting gud buffer is only partially loaded. Using debug-on-error I have the following stack trace:
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<4>> :command nil :noquery nil :file-handler t)
apply(tramp-sh-handle-make-process (:name "gdb-inferior" :buffer #<buffer limbo<4>> :command nil :noquery nil :file-handler t))
tramp-sh-file-name-handler(make-process :name "gdb-inferior" :buffer #<buffer limbo<4>> :command nil :noquery nil :file-handler t)
apply(tramp-sh-file-name-handler make-process (:name "gdb-inferior" :buffer #<buffer limbo<4>> :command nil :noquery nil :file-handler t))
tramp-file-name-handler(make-process :name "gdb-inferior" :buffer #<buffer limbo<4>> :command nil :noquery nil :file-handler t)
tramp-handle-start-file-process("gdb-inferior" #<buffer limbo<4>> nil)
apply(tramp-handle-start-file-process ("gdb-inferior" #<buffer limbo<4>> nil))
tramp-sh-file-name-handler(start-file-process "gdb-inferior" #<buffer limbo<4>> nil)
apply(tramp-sh-file-name-handler start-file-process ("gdb-inferior" #<buffer limbo<4>> nil))
tramp-file-name-handler(start-file-process "gdb-inferior" #<buffer limbo<4>> nil)
apply(tramp-file-name-handler start-file-process "gdb-inferior" #<buffer limbo<4>> nil nil)
#f(compiled-function (name buffer program &rest program-args) "<doc snipped>" #<bytecode 0x40ddd66b>)("gdb-inferior" #<buffer limbo<4>> nil)
apply(#f(compiled-function (name buffer program &rest program-args) "<doc snipped>" #<bytecode 0x40ddd66b>) "gdb-inferior" #<buffer limbo<4>> nil nil)
start-file-process--with-editor-process-filter(#f(compiled-function (name buffer program &rest program-args) "<doc snipped>" #<bytecode 0x40ddd66b>) "gdb-inferior" #<buffer limbo<4>> nil)
apply(start-file-process--with-editor-process-filter #f(compiled-function (name buffer program &rest program-args) "<doc snipped>" #<bytecode 0x40ddd66b>) ("gdb-inferior" #<buffer limbo<4>> nil))
start-file-process("gdb-inferior" #<buffer limbo<4>> nil)
apply(start-file-process "gdb-inferior" #<buffer limbo<4>> nil nil)
comint-exec-1("gdb-inferior" #<buffer limbo<4>> nil nil)
comint-exec(#<buffer limbo<4>> "gdb-inferior" nil nil nil)
make-comint-in-buffer("gdb-inferior" #<buffer limbo<4>> nil)
gdb-inferior-io-mode()
gdb-get-buffer-create(gdb-inferior-io)
gdb-init-1()
gdb-update()
gdb("gdb -i=mi")
funcall-interactively(gdb "gdb -i=mi")
call-interactively(gdb record nil)
command-execute(gdb record)
counsel-M-x-action("gdb")
I am not sure what is going on. I have verified that running gdb on a file locally works, and Emacs is responsive as a front end and properly opens source files and makes break points visible.
Additionally, if I run gud-gdb instead of gdb (with Run gudb-gdb (like this): gdb) I am able to successfully start gdb and use over tramp, but I can only use it from the CLI and not use any of the emacs integration. So I know I can both use Emacs as a gdb front end and access a remote gdb session over tramp, but something breaks putting both of those pieces together.
Can anyone help with this issue? I would really like to be able to use Emacs as a front end to remote gdb. Also let me know if there is any more information I can provide. Thanks in advance!
Note that I snipped the documentation of start-file-process-xxx in several places to clean up the trace. The text where <doc snipped> appears in the trace is here:
Start a program in a subprocess. Return the process object for it. Similar to
start-process, but may invoke a file name handler based ondefault-directory. See Info node(elisp)Magic File Names. This handler ought to run PROGRAM, perhaps on the local host, perhaps on a remote host that corresponds todefault-directory. In the latter case, the local part ofdefault-directory, the one produced from it byfile-local-name, becomes the working directory of the process on the remote host. PROGRAM and PROGRAM-ARGS might be file names. They are not objects of file name handler invocation, so they need to be obtained by callingfile-local-name, in case they are remote file names. File name handlers might not support pty association, if PROGRAM is nil.
