emacs-lsp / dap-mode

Emacs :heart: Debug Adapter Protocol
https://emacs-lsp.github.io/dap-mode
GNU General Public License v3.0
1.29k stars 181 forks source link

Native/C++ Debug produces "Error: write EPIPE when starting a dap session" #350

Closed mark-poscablo closed 4 years ago

mark-poscablo commented 4 years ago

Mac OS Catalina 10.15.6 Spacemacs develop at 15d93914f dap-mode installed through MELPA, located at /Users/mark/.emacs.d/elpa/26.3/develop/dap-mode-20200828.629 Extension located at /Users/mark/.vscode/extensions/webfreak.debug-0.25.0 These lines are inside my dotspacemacs/user-config:

  (setq dap-gdb-lldb-path "/Users/mark/.vscode/extensions/webfreak.debug-0.25.0")
  (setq dap-gdb-lldb-debug-program `("node" , "/Users/mark/.vscode/extensions/webfreak.debug-0.25.0/out/src/gdb.js"))
  (setq dap-gdb-lldb-path-lldb `("node" , "/Users/mark/.vscode/extensions/webfreak.debug-0.25.0/out/src/lldb.js"))

My debug configuration looks like this:

(dap-register-debug-template
  "debug-session"
  (list :type "lldb"
        :request "launch"
        :name "debug-session"
        :target "/Users/mark/devel/myprogram/build/a.out"
        :cwd "/Users/mark/devel/myprogram"))

Running dap-debug (SPC m d d d) will:

Error: write EPIPE at afterWriteDispatched (internal/stream_base_commons.js:154:25) at writeGeneric (internal/stream_base_commons.js:145:3) at Socket._writeGeneric (net.js:782:11) at Socket._write (net.js:794:8) at writeOrBuffer (_stream_writable.js:352:12) at Socket.Writable.write (_stream_writable.js:303:10) at MI2_LLDB.sendRaw (/Users/mark/.vscode/extensions/webfreak.debug-0.25.0/out/src/backend/mi2/mi2.js:766:32) at /Users/mark/.vscode/extensions/webfreak.debug-0.25.0/out/src/backend/mi2/mi2.js:793:18 at new Promise () at MI2_LLDB.sendCommand (/Users/mark/.vscode/extensions/webfreak.debug-0.25.0/out/src/backend/mi2/mi2.js:780:16) Emitted 'error' event on Socket instance at: at emitErrorNT (internal/streams/destroy.js:100:8) at emitErrorCloseNT (internal/streams/destroy.js:68:3) at processTicksAndRejections (internal/process/task_queues.js:84:21) { errno: -32, code: 'EPIPE', syscall: 'write' }

Process debug-session stderr finished



Anyone have ideas on what's happening here?
yyoncho commented 4 years ago

I would start by checking if lldb binary is present (as per debug adapter docs). Also, make sure that you are using recent nodejs.

mark-poscablo commented 4 years ago

Looked around some more, and I got past this issue. Here are the details for anyone else who might encounter this:

Root issue: lldb-mi could not be found in the PATH

Applied workaround:

Alternative workaround:

mark-poscablo commented 4 years ago

I would start by checking if lldb binary is present (as per debug adapter docs). Also, make sure that you are using recent nodejs.

Yes, thanks I actually just got past this minutes before your comment. I appreciate it!

mark-poscablo commented 4 years ago

I would start by checking if lldb binary is present (as per debug adapter docs). Also, make sure that you are using recent nodejs.

@yyoncho Would you know if there's a presently working solution that uses lldb-vscode instead? I was actually using https://github.com/lanza/lldb-vscode.git a while ago before upgrading the MELPA dap-mode package to 20200828.629 (actually 20200823.1511 that time), but after the upgrade everything got wrecked and I kept on getting Wrong type argument: stringp, nil. I should mention though that I had to edit .emacs.d/layers/+lang/c-c++/funcs.el to use dap-lldb instead though for this previous solution to work:

(defun spacemacs//c-c++-setup-lsp-dap ()
  "Setup DAP integration."
  ;;(require 'dap-gdb-lldb))
  (require 'dap-lldb))
yyoncho commented 4 years ago

@yyoncho Would you know if there's a presently working solution that uses lldb-vscode instead?

I am not using lldb/gdb related debugger. ATM there are no open issues related to that debugger so I assume that it should work.

I kept on getting Wrong type argument: stringp, nil

I need a callstack for that.

to use dap-lldb instead though for this previous solution to work:

You could put something like (with-eval-after-load 'dap-mode (require '...)) in your user config.

mark-poscablo commented 4 years ago

@yyoncho here's the call stack

I kept on getting Wrong type argument: stringp, nil

I need a callstack for that.

Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  make-process(:name "debug-session" :connection-type pipe :coding no-conversion :command ("/Users/mark/.vscode/extensions/lanza.lldb-vscode-0.2.2/bin/darwin/bin/lldb-vscode" nil) :stderr "*debug-session stderr*" :noquery t)
  dap--create-session((:type "lldb" :request "launch" :name "debug-session" :target "/Users/mark/devel/myprogram/build/myprogram" :cwd "/Users/mark/devel/myprogram" :dap-server-path ("/Users/mark/.vscode/extensions/lanza.lldb-vscode-0.2.2/bin/darwin/bin/lldb-vscode" nil) :program "/Users/mark/devel/myprogram/main.cpp"))
  dap-start-debugging((:type "lldb" :request "launch" :name "debug-session" :target "/Users/mark/devel/myprogram/build/myprogram" :cwd "/Users/mark/devel/myprogram" :dap-server-path ("/Users/mark/.vscode/extensions/lanza.lldb-vscode-0.2.2/bin/darwin/bin/lldb-vscode") :program "/Users/mark/devel/myprogram/main.cpp"))
  dap-debug((:type "lldb" :request "launch" :name "debug-session" :target "/Users/mark/devel/myprogram/build/myprogram" :cwd "/Users/mark/devel/myprogram" :dap-server-path ("/Users/mark/.vscode/extensions/lanza.lldb-vscode-0.2.2/bin/darwin/bin/lldb-vscode") :program "/Users/mark/devel/myprogram/main.cpp"))
  funcall-interactively(dap-debug (:type "lldb" :request "launch" :name "debug-session" :target "/Users/mark/devel/myprogram/build/myprogram" :cwd "/Users/mark/devel/myprogram" :dap-server-path ("/Users/mark/.vscode/extensions/lanza.lldb-vscode-0.2.2/bin/darwin/bin/lldb-vscode") :program "/Users/mark/devel/myprogram/main.cpp"))
  call-interactively(dap-debug nil nil)
  command-execute(dap-debug)
yyoncho commented 4 years ago

see https://github.com/emacs-lsp/dap-mode/issues/346

mark-poscablo commented 4 years ago

see #346

Thanks that looks like the actual problem here. Appreciate the link.