Debug adapter process has terminated unexpectedly about code-debug HOT 17 CLOSED

you have a dot at the start of your target indicating that it's a relative path, even though it's an absolute path

from code-debug.

I suggest just replacing it to ./target/debug/one and it should work

from code-debug.

That didnt work. I tried mucking with both absolute and relative paths as well.

from code-debug.

Can you post the error log at the bottom in the debug output?

from code-debug.

Thanks for reopening @WebFreak001
Unfortunately I don't see anything in the debug console, which makes it all the more harder to trace.
Is there an adaptor log posted in any folder that I can trace or send to you?

from code-debug.

The first time around, I had issues with python and gdb aka
The message "No module named gdb" was appearing in the debug console.

Thereafter I reinstalled gdb with python support
./configure --with-python=/usr/local

After this, i started receiving this error with no cues in the console

from code-debug.

The debug console will open if you open the command palette and then run Debug: Debug Console

If it doesn't fill with anything after starting then there is probably something broken with your gdb or vscode can't run it. Make sure you can run gdb in the console and then try starting vscode from that console where you just ran gdb and try again

from code-debug.

Tried as you recommended and no luck
gdb$ shell
shell$code

.. and no luck, same issue and no log lines in debug console.

I see this pattern repeat with both my mabooks (el capitan) .
I installed GDB via brew and followed the exact steps : https://medium.com/@royalstream/how-to-install-and-codesign-gdb-on-os-x-el-capitan-aab3d1172e95#.ua8zgn1nb

from code-debug.

Extracted logs via Developer tools in vscode . Hope this can help

146510492998.txt

from code-debug.

Identified the issue. The root cause was .gdbinit (module to enable rust pretty printing)

However, by removing this file, I have lost pretty printing

.gdbinit contents

python
import sys
print " — — Loading Rust pretty-printers — — "
sys.path.insert(0, "/Users/chetanconikee/.multirust/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/etc")
import gdb_rust_pretty_printing
gdb_rust_pretty_printing.register_printers(gdb)
end

On removing .gdbinit the issue was resolved ...

from code-debug.

Stumbled on a new issue.

On initiating a debug, any breakpoint shifts to being a "unverified breakpoint" and the debug console says "running executable"

Note that there is no .gdbinit this time around.

Any cues to what might lead to this?

from code-debug.

I finally resolved all issue.

Steps:

1. Reinstalled GDB
2. codesign -fs gdb-cert /usr/local/bin/gdb
3. .gdbinit contents (to resolve pretty printing)
   ~ start ~
   python
   import sys;
   sys.path.append("/Users/XXX/.multirust/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/etc")
   print "Loading Rust Pretty Printers"
   sys.path.insert(0, "/Users/XXX/.multirust/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/etc")
   import gdb_rust_pretty_printing
   gdb_rust_pretty_printing.register_printers(gdb)
   ~ end ~
4. Restarted vscode and everything is working as expected

Thanks @WebFreak001 for all your support on this.

I will publish a blog post to ensure that someone else does not stumble on the same issue as I did

BTW: Most of the issues stemmed from "codesign" and ".gdbinit" as there was no exception or error messages indicating reason for failure

from code-debug.

Oh, right. It was probably something in the gdbinit. I could actually disable loading the gdbinit, but that would prevent people from customizing the startup, so I won't do that and instead let the user fix his gdbinit file if there are any issues.

from code-debug.

I get the exact same issue, even following the steps posted by @conikeec above. Oddly, running gdb from the command line (gdb executable) doesn't give any errors, and can successfully load the pretty-printer.

from code-debug.

It's because of the pretty-printer. Characters like ~ after a number or after nothing are treated as commands for code-debug. This is how gdb sends commands to the GUI app. I could actually modify it, so it only happens if you have something like CodeDebug_[number]~ instead of just [optional number]~ but it might skip on a few commands then and instead output them to the console

from code-debug.

@WebFreak001 Trying to follow here (at the end of a long week!): are you saying that this plugin for VS Code just won't support pretty-printing with Rust at all? Or am I misreading you? (Not upset either way; I appreciate your work on this. Just trying to figure out what the status here is.)

from code-debug.

Not 100% sure what exactly caused the issue but as long as Rust pretty-printing won't look like GDB/MI commands it might actually still work. I don't know how Rust pretty-printing looks like so I can't really say anything about that. Maybe this was just an issue for this one person, best way to figure that out is by just trying yourself if it crashes when pretty-printing and then only disabling pretty-printing to see if it works after that.

For reference: A line starting with *, +, =, ~, @, &, ^ might cause issues or even crash. If you want to output anything starting with those characters, you should prepend & before it (log-stream-output). Here is the related code for parsing those lines: https://github.com/WebFreak001/code-debug/blob/master/src/backend/mi_parse.ts#L88

from code-debug.