emacs-lsp / dap-mode

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

overlay issues with breakpoints causing debug to fail #193

Open rileyrg opened 4 years ago

rileyrg commented 4 years ago

("dap-mode" . "9d08eaf77d4aeb80880be85bc0591554314d0eb7")

This happens reasonably frequently and I need to quit and restart to fix it. If I can reliably reproduce I'll let you know, but possibly this trace is sufficient to spot the falling down bit.

I start my debug on entry PHP config. Buffer sits there happily waiting on a connection.

I fire up the web page to trigger the debug:-

Debugger entered--Lisp error: (wrong-type-argument overlayp nil) delete-overlay(nil) mapc(delete-overlay (nil)) dap-ui--clear-breakpoint-overlays() dap-ui--refresh-breakpoints() run-hooks(dap-breakpoints-changed-hook) dap--update-breakpoints(#s(dap--debug-session :name "Php SOE Debug" :last-id 6 :proc # :response-handlers #<hash-table eql 2/65 0x157c86eb4419> :parser #s(dap--parser :waiting-for-response nil :response-result nil :headers nil :body nil :reading-body nil :body-length nil :body-received nil :leftovers "") :output-buffer #<buffer Php SOE Debug out> :thread-id nil :workspace nil :threads (#<hash-table equal 2/65 0x157c86a2ca89>) :thread-states #<hash-table eql 1/65 0x157c872fda41> :active-frame-id nil :active-frame nil :cursor-marker nil :state pending :breakpoints #<hash-table equal 2/65 0x157c86f671f1> :thread-stack-frames #<hash-table eql 0/65 0x157c8706c5b5> :launch-args (:type "php" :cwd "/home/rgr/Dropbox/homefiles/development/Symfony/kn..." :request "launch" :name "Php SOE Debug" :stopOnEntry t :sourceMaps t :dap-server-path ("node" "/home/rgr/.emacs.d/.extension/vscode/felixfbecker....")) :initialize-result #<hash-table equal 6/65 0x157c86f606f9> :error-message nil :loaded-sources nil) #<hash-table equal 6/65 0x157c86fd6ab1> "/home/rgr/.emacs.d/config.org")

f(compiled-function (resp) #<bytecode 0x157c86c2cb59>)(#<hash-table equal 6/65 0x157c86fd6ab1>)

f(compiled-function (input0) #<bytecode 0x157c86c2cb75>)(#<hash-table equal 6/65 0x157c86fd6ab1>)

f(compiled-function (m) #<bytecode 0x157c87308cc1>)("{\"seq\":7,\"type\":\"response\",\"request_seq\":5,\"comman...")

mapc(#f(compiled-function (m) #<bytecode 0x157c87308cc1>) ("{\"seq\":6,\"type\":\"response\",\"request_seq\":4,\"comman..." "{\"seq\":7,\"type\":\"response\",\"request_seq\":5,\"comman..." "{\"seq\":8,\"type\":\"response\",\"request_seq\":6,\"comman..."))

f(compiled-function (_ msg) #<bytecode 0x157c870017b9>)(# "Content-Length: 138\15\n\15\n{\"seq\":6,\"type\":\"response\",...")

coconutpalm commented 3 years ago

I'm seeing this in typescript-mode too

RKBK commented 3 years ago

@rileyrg @coconutpalm I was adviced by @yyoncho today that you could try to delete ~/.emacs.d/.dap-breakpoints (and then possibly restart emacs) to fix this issue. That worked in my case, where the .dap-breakpoints file seemed to include a break point in my main org-mode file.

jsravn commented 3 years ago

And in go-mode too for me.

yyoncho commented 3 years ago

pushed a fix to avoid that issue. After it, it shouldn't be possible to hit it again.