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
  • 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("gdb -i=mi")
  funcall-interactively(gdb "gdb -i=mi")
  call-interactively(gdb record nil)
  command-execute(gdb record)

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 on default-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 to default-directory. In the latter case, the local part of default-directory, the one produced from it by file-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 calling file-local-name, in case they are remote file names. File name handlers might not support pty association, if PROGRAM is nil.

1 Answer 1


This is bug#44151, see https://debbugs.gnu.org/44151. I've fixed this in Tramp, which will be released later today on GNU ELPA. Note that this bug describes a further problem, which seems to be in gdb-mi.el. This I couldn't fix.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.