vadimcn / codelldb Goto Github PK

In the case of Rust, I can see the primitive types supported already by LLDB and the plugin.

However, for more complex data structures (like variables from external libraries such as 'hyper'), plain LLDB is not sufficient. rust-lldb seems to work and it support the same exact arguments as the original LLDB.

Since both exist in our $PATH, it would be trivial to add support for calling a LLDB executable other than the default one.

An imaginary example: (notice the lldb_path variable)

{
            "type": "lldb",
            "request": "launch",
            "name": "Launch",
            "lldb_path": "~/.cargo/bin/lldb-rust",
            "program": "${workspaceRoot}/target/debug/RustTests",
            "args": [],
            "cwd": "${workspaceRoot}",
            "sourceLanguages": ["rust"]
        }

Then, when debugging, the value from "lldb_path" would be called as the lldb, instead of the default one.

I believe that small addition would be the killer feature for this plugin, as it is the only one that comes even close to having debug functionalities w/ Rust (other ones I tested don't work at all).

Does that seem possible?

Which OS:Ubuntu 17.04
Which LLDB version (lldb -version):4.0
Which VSCode version (Help/About): 1.12.2

What is the problem and how did you get there:

/py
error: '/py' is not a valid command.
error: Unrecognized command '/py'.

/nat
error: '/nat' is not a valid command.
error: Unrecognized command '/nat'.

What did you expect to have happened instead (if not obvious):

Which OS: Windows 7
Which LLDB version (lldb -version): 5.0.0
Which VSCode version (Help/About): 1.10.1

What is the problem and how did you get there:
I installed the LLDB extension to debug a Rust program. However a "Step over (F10)" always results in a "Step Into (F11)", both using the buttons and the key shortcuts.

This is my launch file.

{
    "version": "0.2.0",
    "configurations": [
        {
            "type": "lldb",
            "request": "launch",
            "name": "Debug LLDB",
            "program": "${workspaceRoot}/target/debug/program.exe",
            "args": [],
            "cwd": "${workspaceRoot}",
            "preLaunchTask": "cargo",
            "sourceLanguages": [
                "rust"
            ]
        }
    ]
}

Which OS: macOS Sierra 10.12.3
Which LLDB version (lldb -version): lldb-360.1.70
Which VSCode version (Help/About): 1.8.1

This is not a bug, but perhaps something to add to the readme. I will gladly create a pull request with a modified readme if you would like. Just let me know.

I was attempting to debug a Rust library that I downloaded from GitHub. I set a breakpoint in one of the tests, modified my launch.json to point to the test executable, and started the debugger.

I received this error in the VS Code debug console

dyld: Library not loaded: @rpath/librustc-f454ab7c662222f0.dylib

I had to add this to my launch.json so that LLDB could find the shared libraries.

"env": {
"DYLD_LIBRARY_PATH": "${env.HOME}/.rustup/toolchains/nightly-x86_64-apple-darwin/lib"
}

Which OS: Fedora 24
Which LLDB version (lldb -version): 3.8.0
Which VSCode version (Help/About): 17.1

What is the problem and how did you get there:
When I try to debug I get:
Debug adapter process has terminated unexpectedly

Launch.json:
{
"version": "0.2.0",
"configurations": [
{
"name": "Debug",
"type": "lldb",
"request": "launch",
"program": "/home/username/Fractal/user-panel/target/debug/fractal-website",
"cwd": "${workspaceRoot}",
"args": ["--no-default-features"],
"env": "RUST_BACKTRACE=1",
"sourceLanguages": ["rust"],
"stopOnEntry": true
}
]
}

Went through instructions and troubleshooting. LLDB seems to work on it's own.. though I only got it to the point that it started running, just not through VSCode.

What did you expect to have happened instead (if not obvious):
The program to debug

Note that lldb -version shows error:
ImportError: No module named lldb.embedded_interpreter, can't figure out how to install a module.. maybe that's needed though?

Which OS: MacOS 10.12.4
Which LLDB version (lldb -version): lldb-370.0.42
Which VSCode version (Help/About): 1.12.2

Problem: When inspecting values passed as references, the addresses appear to be shown rather than the value at that address.

Expected: Inspect the value the same as if it was passed without the & reference (e.g. as if calling ?/nat *expr in the debug console)

Which OS: mac osx Sierra 10.12.4
Which LLDB version (lldb -version):

lldb -v                                                                                      
lldb-370.0.40
  Swift-3.1

Which VSCode version (Help/About):
1.11.2
What is the problem and how did you get there:
I used this config:

 {
	"type": "lldb",
	"request": "launch",
	"name": "C++ Debug",
	"program": "${workspaceRoot}/bin/${fileBasenameNoExtension}",
	"args": [],
	"cwd": "${workspaceRoot}"
}

When I debug my cpp code, I get:

Internal debugger error:
Traceback (most recent call last):
  File "/Users/xxx/.vscode/extensions/vadimcn.vscode-lldb-0.4.1/adapter/debugsession.py", line 888, in handle_message
    result = handler(args)
  File "/Users/xxx/.vscode/extensions/vadimcn.vscode-lldb-0.4.1/adapter/debugsession.py", line 91, in DEBUG_launch
    self.target = self.create_target(args)
  File "/Users/xxx/.vscode/extensions/vadimcn.vscode-lldb-0.4.1/adapter/debugsession.py", line 189, in create_target
    target = self.debugger.CreateTarget(str(program), None, None, load_dependents, error)
UnicodeEncodeError: 'ascii' codec can't encode characters in position 30-34: ordinal not in range(128)

What did you expect to have happened instead (if not obvious):
Of course I can debug with lldb~;)

There are no HOME, PATH... etc variables in environment.
Platform: OSX
Version of extension: master from github.

Which OS: Ubuntu 17.04/MacOS 10.12.x
Which LLDB version (lldb -version): 4.0.0
Which VSCode version (Help/About): 1.13

What is the problem and how did you get there:
Trouble running from source.

Hello,

I'm trying to get the source up and running. I can launch an extension host and adapter debug session.
I first had to modify my LLDB's python (ubuntu 17.04) import code as it was looking for a different _lldb.so file.
I could then get as far as the adapter launching the debugger:
self.process = self.target.Launch(self.event_listener,   target_args, envp, stdio[0], stdio[1], stdio[2],   work_dir, flags, stop_on_entry, error)

This was first failing with the error that lldb-server-4.0.0 could not be found. I worked around this by creating a symlink for to the existing lldb-server-4.0.
The launch step now fails with what looks like a protocol error between the lldb-server and python client

'A' packet returned an error:

Any tips for getting this to work or setting up my environment?

Thanks

Which OS: MacOs 10.12.4 (16E195)
Which LLDB version (lldb -version): lldb-370.0.42
Which VSCode version (Help/About): 1.12.1

What is the problem and how did you get there: Inspecting a string requires drilling down and only shows the first char.

What did you expect to have happened instead (if not obvious):
Show the string value, in full.

Hi, thanks for this plugin. Took me hours and hours to finally get to debug rust, so thanks for that!

Which OS:

ProductName:	Mac OS X
ProductVersion:	10.12.5
BuildVersion:	16F73

Which LLDB version (lldb -version):

lldb-370.0.42
  Swift-3.1

Which VSCode version (Help/About):

1.12.2
19222cdc84ce72202478ba1cec5cb557b71163de

What is the problem and how did you get there:

I passed all of the troubleshootings,
but I used the ~/tmp/fix_brew_python.py in ~/.lldbinit
for brew installed python.

command script import ~/tmp/fix_brew_python.py

Even though, I got the error:

Error: Debug adapter process has terminated unexpectedly

What did you expect to have happened instead (if not obvious):

Although, I set the lldb.log, but no output.

So I am debugging a Rust program that is interactive (through stdin).

This is my config:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Debug",
            "type": "lldb",
            "request": "launch",
            "program": "${workspaceRoot}/target/debug/rust-calculus",
            "args": []
        }
    ]
}

And I launch the program with the debugger and it works as expected but I cannot access stdin.

So I specify "stdio": "*" , but now when launching the debugger, it just hangs (with that little blue bar under the debugger launcher just going and going).

Which OS: linux
Which LLDB version (lldb -version): 4.0
Which VSCode version (Help/About): Latest

Hi,

This is more of a request for a pointer than anything else, I'm using/adapting LLDBCode for a niche language (Fabric Engines KL), and VSCode can't find source files when debugging.

Is there anywhere in you plugin that I could modify to change the path VSCode is searching?

Note - I can partially resolve this using
"preRunCommands" : [
"settings set target.source-map // /SomeSubFolder/"
],

which changes the source search path for LLDB, but if I could modify the output from LLDB -> VSCode I could apply much better heuristics (and not manually setup search paths for every root folder)

Any assistance hugely helpful!

And thanks for the awesome plugin!

Tried with lldb 3.7, 3.8 and 3.9
When debugging is started,

"Unable to start debugging. Unable to establish a connection to LLDB. Debug output may contain more information." is shown

The console simply show the usage help:

Usage:

  lldb -h
  lldb -v [[--] <PROGRAM-ARG-1> [<PROGRAM_ARG-2> ...]]
  lldb -a <arch> -f <filename> [-c <filename>] [-s <filename>] [-o <none>] [-S <filename>] [-O <none>] [-k <none>] [-K <filename>] [-Q] [-b] [-e] [-x] [-X] [-l <script-language>] [-d] [[--] <PROGRAM-ARG-1> [<PROGRAM_ARG-2> ...]]
  lldb -n <process-name> -w [-s <filename>] [-o <none>] [-S <filename>] [-O <none>] [-k <none>] [-K <filename>] [-Q] [-b] [-e] [-x] [-X] [-l <script-language>] [-d]
  lldb -p <pid> [-s <filename>] [-o <none>] [-S <filename>] [-O <none>] [-k <none>] [-K <filename>] [-Q] [-b] [-e] [-x] [-X] [-l <script-language>] [-d]
  lldb -P

       -h 
       --help 
            Prints out the usage information for the LLDB debugger.

       -v 
       --version 
            Prints out the current version number of the LLDB debugger.

       -a <arch>
       --arch <arch>
            Tells the debugger to use the specified architecture when starting
            and running the program.  <architecture> must be one of the
            architectures for which the program was compiled.

       -f <filename>
       --file <filename>
            Tells the debugger to use the file <filename> as the program to be
            debugged.

       -c <filename>
       --core <filename>
            Tells the debugger to use the fullpath to <path> as the core file.

       -p <pid>
       --attach-pid <pid>
            Tells the debugger to attach to a process with the given pid.

       -n <process-name>
       --attach-name <process-name>
            Tells the debugger to attach to a process with the given name.

       -w 
       --wait-for 
            Tells the debugger to wait for a process with the given pid or name
            to launch before attaching.

       -s <filename>
       --source <filename>
            Tells the debugger to read in and execute the lldb commands in the
            given file, after any file provided on the command line has been
            loaded.

       -o 
       --one-line 
            Tells the debugger to execute this one-line lldb command after any
            file provided on the command line has been loaded.

       -S <filename>
       --source-before-file <filename>
            Tells the debugger to read in and execute the lldb commands in the
            given file, before any file provided on the command line has been
            loaded.

       -O 
       --one-line-before-file 
            Tells the debugger to execute this one-line lldb command before any
            file provided on the command line has been loaded.

       -k 
       --one-line-on-crash 
            When in batch mode, tells the debugger to execute this one-line
            lldb command if the target crashes.

       -K <filename>
       --source-on-crash <filename>
            When in batch mode, tells the debugger to source this file of lldb
            commands if the target crashes.

       -Q 
       --source-quietly 
            Tells the debugger to execute this one-line lldb command before any
            file provided on the command line has been loaded.

       -b 
       --batch 
            Tells the debugger to running the commands from -s, -S, -o & -O,
            and then quit.  However if any run command stopped due to a signal
            or crash, the debugger will return to the interactive prompt at the
            place of the crash.

       -e 
       --editor 
            Tells the debugger to open source files using the host's "external
            editor" mechanism.

       -x 
       --no-lldbinit 
            Do not automatically parse any '.lldbinit' files.

       -X 
       --no-use-colors 
            Do not use colors.

       -P 
       --python-path 
            Prints out the path to the lldb.py file for this version of lldb.

       -l <script-language>
       --script-language <script-language>
            Tells the debugger to use the specified scripting language for
            user-defined scripts, rather than the default.  Valid scripting
            languages that can be specified include Python, Perl, Ruby and Tcl.
            Currently only the Python extensions have been implemented.

       -d 
       --debug 
            Tells the debugger to print out extra information for debugging
            itself.


  Notes:

       Multiple "-s" and "-o" options can be provided.  They will be processed from left to right in order, 
       with the source files and commands interleaved.  The same is true of the "-S" and "-O" options.
       The before file and after file sets can intermixed freely, the command parser will sort them out.
       The order of the file specifiers ("-c", "-f", etc.) is not significant in this regard.

Which OS: macOS Sierra 10.12.3
Which LLDB version (lldb -version): lldb-360.1.70
Which VSCode version (Help/About): 1.10.2 (1.10.2)

What is the problem and how did you get there:
Only message I'm getting is

Debug adapter process has terminated unexpectedly

What did you expect to have happened instead (if not obvious):
I figure out reason why it is failing, not sure how to fix it, though. Basically, if I'm doing this in llvm:

➜ lldb
(lldb) script import io
Traceback (most recent call last):
  File "<input>", line 1, in <module>
  File "/usr/local/Cellar/python/2.7.13/Frameworks/Python.framework/Versions/2.7/lib/python2.7/io.py", line 51, in <module>
    import _io
ImportError: dlopen(/usr/local/Cellar/python/2.7.13/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_io.so, 2): Symbol not found: __PyCodecInfo_GetIncrementalDecoder
  Referenced from: /usr/local/Cellar/python/2.7.13/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_io.so
  Expected in: flat namespace
 in /usr/local/Cellar/python/2.7.13/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_io.so
(lldb) 

I found similar issue here snare/voltron#111

So, what I did to fix the issue:

mkdir -p ~/tmp
curl https://gist.githubusercontent.com/snare/88bca2a34f00dc6b0fe17679c5082529/raw/fix_brew_python.py --output ~/tmp/fix_brew_python.py
echo "command script import ~/tmp/fix_brew_python.py" >> ~/.lldbinit

Afterwards everything works.
I suggest similar changes to snare/voltron#111 to actually fix the issue or add script import io to troubleshooting steps if not fixed.

Which OS: OSX
Which LLDB version (lldb -version): lldb-350.0.21.9
Which VSCode version (Help/About): 1.6.1

What is the problem and how did you get there:
Setting a breakpoint on any line within a header results in a hollow gray circle in the gutter and a tooltip "Unverified breakpoint". The breakpoint does not stop the execution.

What did you expect to have happened instead (if not obvious):
The breakpoint should be set and stop the execution. This is what happens with the default C++ debugger backend. Breakpoints in non-header source files work as expected.

Which OS: OSX 10.11.6
Which LLDB version (lldb -version): lldb-350.0.21.9
Which VSCode version (Help/About): Version 1.9.0-insider (1.9.0-insider)

What is the problem and how did you get there: Trying to step-thru debug a simple C++ application and I keep seeing the following errors over and over in the DEBUG CONSOLE:

Internal debugger error:
Traceback (most recent call last):
  File "./adapter/debugsession.py", line 695, in handle_message
    result = handler(args)
  File "./adapter/debugsession.py", line 477, in DEBUG_evaluate
    return self.evaluate_expr(args, expr)
  File "./adapter/debugsession.py", line 501, in evaluate_expr
    raise Exception('Missing frameId')
Exception: Missing frameId
[10:53:42 debugsession] Internal debugger error:
Traceback (most recent call last):
  File "./adapter/debugsession.py", line 695, in handle_message
    result = handler(args)
  File "./adapter/debugsession.py", line 477, in DEBUG_evaluate
    return self.evaluate_expr(args, expr)
  File "./adapter/debugsession.py", line 501, in evaluate_expr
    raise Exception('Missing frameId')
Exception: Missing frameId

The application's output is not affected but get buried since this message prints many many times.

Which OS: macOS 10.12.5
Which LLDB version (lldb -version): lldb-370.0.42 Swift-3.1
Which VSCode version (Help/About):
Which plugin version: 0.5.2

Previously, when on a breakpoint it was possible to see the contents of a string value as a string. Now, instead it shows as alloc::string::String, and there's no clear way to access the contents.

Expected: Ability to access the string's contents.

Which OS:
Linux
Which LLDB version (lldb -version):
4.0.0
Which VSCode version (Help/About):
1.11.2
What is the problem and how did you get there:

When setting a breakpoint inside one mod.rs file, a breakpoint is set on all mod.rs files that are in the program.

What did you expect to have happened instead (if not obvious):

The breakpoint should be set on one mod.rs file

My guess is that the root cause is that a command along the line "b mod.rs:100" get sent to the debugger, which ambiguous (it should include more parts of the file path...).

example output of breakpoint list:
(here, breakpoints 2.6 - 2.8 are the only ones desired)

2: file = 'mod.rs', line = 397, exact_match = 0, locations = 13, resolved = 3, hit count = 1
  2.1: where = magicstick`futures::sync::mpsc::{{impl}}::inc_num_messages<magicstick::client::Packet> + 350 at mod.rs:397, address = 0x00005613531d4c3e, unresolved, hit count = 0  Options: disabled 
  2.2: where = magicstick`futures::sync::mpsc::{{impl}}::inc_num_messages<tokio_core::reactor::Message> + 350 at mod.rs:397, address = 0x00005613531d4e6e, unresolved, hit count = 0  Options: disabled 
  2.3: where = magicstick`futures::sync::mpsc::{{impl}}::inc_num_messages<tokio_core::reactor::Message> + 350 at mod.rs:397, address = 0x0000561353237cbe, unresolved, hit count = 0  Options: disabled 
  2.4: where = magicstick`futures::sync::mpsc::{{impl}}::inc_num_messages<i32> + 350 at mod.rs:397, address = 0x0000561353237eee, unresolved, hit count = 0  Options: disabled 
  2.5: where = magicstick`futures::sync::mpsc::{{impl}}::inc_num_messages<tokio_core::reactor::Message> + 350 at mod.rs:397, address = 0x00005613532649de, unresolved, hit count = 0  Options: disabled 
  2.6: where = magicstick`magicstick::ibeacon::{{impl}}::read + 126 at mod.rs:397, address = 0x000056135321b5fe, resolved, hit count = 1 
  2.7: where = magicstick`magicstick::ibeacon::{{impl}}::read + 149 at mod.rs:397, address = 0x000056135321b615, resolved, hit count = 0 
  2.8: where = magicstick`magicstick::ibeacon::{{impl}}::read + 375 at mod.rs:397, address = 0x000056135321b6f7, resolved, hit count = 0 
  2.9: where = magicstick`futures::task_impl::{{impl}}::poll_stream<futures::sync::mpsc::UnboundedReceiver<tokio_core::reactor::Message>> + 92 at mod.rs:397, address = 0x000056135326408c, unresolved, hit count = 0  Options: disabled 
  2.10: where = magicstick`futures::task_impl::{{impl}}::poll_stream<futures::sync::mpsc::UnboundedReceiver<tokio_core::reactor::Message>> + 110 at mod.rs:397, address = 0x000056135326409e, unresolved, hit count = 0  Options: disabled 
  2.11: where = magicstick`tokio_core::reactor::{{impl}}::consume_timeouts + 398 at mod.rs:397, address = 0x000056135328349e, unresolved, hit count = 0  Options: disabled 
  2.12: where = magicstick`tokio_core::reactor::{{impl}}::consume_timeouts + 1348 at mod.rs:397, address = 0x0000561353283854, unresolved, hit count = 0  Options: disabled 
  2.13: where = magicstick`core::iter::{{impl}}::next<core::slice::Iter<futures::task_impl::UnparkEvent>,futures::task_impl::UnparkEvent> + 23 at mod.rs:410, address = 0x00005613532a9727, unresolved, hit count = 0  Options: disabled 

Which OS: mac os 10.12
Which LLDB version (lldb -version): lldb-360.1.50
Which VSCode version (Help/About): 0.3.0

What is the problem and how did you get there:
when debug to code:
println!(" derivative y^2-x:{}", dx(1.0));
prompt the error:
Source /Users/rustbuild/src/rust-buildbot/slave/nightly-dist-rustc-mac/build/src/libcore/fmt/mod.rs is not available.

What did you expect to have happened instead (if not obvious):
rust src path : /Users/polus/.multirust/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/src/rust/src

http://dlang.org/spec/arrays.html#dynamic-arrays
http://dlang.org/spec/hash-map.html
http://docs.algorithm.dlang.io/latest/mir_ndslice_slice.html#.Slice

I can help with that, but have no idea how to do it in general.

Which OS: windows 7 64bit
Which LLDB version (lldb -version): lldb version 5.0.0 32bit
Which Python version: 13.6.1 32bit1
Which VSCode version (Help/About): 11.14.1 64bit

What is the problem and how did you get there:
1, create a rust project with cargo new
2, try to debug it
3, an error occured:

(lldb) script import sys, io, lldb; print(lldb.SBDebugger.Create().GetVersionString()); print("OK")
error: your copy of LLDB does not support scripting.
---
An exception was raised while launching debugger: { Error: The debugger exited without completing startup handshake.
at ChildProcess.lldb.on (C:\Users\Bruce.vscode\extensions\vadimcn.vscode-lldb-0.5.2\out\startup.js:153:27)
at emitTwo (events.js:106:13)
at ChildProcess.emit (events.js:191:7)
at Process.ChildProcess._handle.onexit (internal/child_process.js:215:12)
code: 'Handshake',
stdout: '(lldb) script import sys, io, lldb; print(lldb.SBDebugger.Create().GetVersionString()); print("OK")\r\n' }

What did you expect to have happened instead (if not obvious):
debug functions ok

Regardless what I have in stopOnEntry, when I attach to a running process, the debugger always stops it and I have to manually enter continue. It would be great the stopOnEntry is honored in attaching as well.

Thanks!

We would like to use vscode-lldb for opening a core dump c++ in Mac ,can we do it using vscode-lldb.
Can you give me your email.
best regards

Which OS: OSX
Which LLDB version (lldb -version): 0.3.3
Which VSCode version (Help/About): 1.9.0

What is the problem and how did you get there:

VSCode error during debug: "Unexpected token C in JSON at position 2. Stopping the debug adapter." if some break-point is set. lldb process hangs in task manager.

Reference demangle implementation can be found at https://github.com/dlang/druntime/blob/master/src/core/demangle.d

Which OS: MacOS 10.12.4
Which LLDB version (lldb -version): lldb-370.0.42 / Swift-3.1
Which VSCode version (Help/About): 1.12.2

What is the problem and how did you get there: Debugging a hung Rust program,
I did process interrupt, then started back tracing the threads, and on couple of the threads I get the following error:

thread backtrace 3
Internal debugger error: 'utf8' codec can't decode byte 0xe3 in position 1432: invalid continuation byte
Internal debugger error:
Traceback (most recent call last):
  File "/Users/nikolay/.vscode/extensions/vadimcn.vscode-lldb-0.4.1/adapter/debugsession.py", line 888, in handle_message
    result = handler(args)
  File "/Users/nikolay/.vscode/extensions/vadimcn.vscode-lldb-0.4.1/adapter/debugsession.py", line 638, in DEBUG_evaluate
    self.console_msg(output)
  File "/Users/nikolay/.vscode/extensions/vadimcn.vscode-lldb-0.4.1/adapter/debugsession.py", line 1064, in console_msg
    self.send_event('output', { 'category': 'console', 'output': output })
  File "/Users/nikolay/.vscode/extensions/vadimcn.vscode-lldb-0.4.1/adapter/debugsession.py", line 1060, in send_event
    self.send_message(message)
  File "/Users/nikolay/.vscode/extensions/vadimcn.vscode-lldb-0.4.1/adapter/wireprotocol.py", line 75, in send_message
    data = json.dumps(message, separators=self.json_separators)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/json/__init__.py", line 250, in dumps
    sort_keys=sort_keys, **kw).encode(obj)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/json/encoder.py", line 207, in encode
    chunks = self.iterencode(o, _one_shot=True)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/json/encoder.py", line 270, in iterencode
    return _iterencode(o, 0)
UnicodeDecodeError: 'utf8' codec can't decode byte 0xe3 in position 1432: invalid continuation byte

Which OS: macOS 10.12.4
Which LLDB version (lldb -version): lldb-370.0.42 Swift-3.1
Which VSCode version (Help/About): 1.11.2 (1.11.2)
What is the problem and how did you get there:

I was trying to debug an Option matching. But the value of T was not present, on the watch window, only the type, if you look closely the watch tab is expanded in the editor but there is nothing in there.

What did you expect to have happened instead (if not obvious):

I expected the value of T to be present there. The problem may be that the value is a custom Enum type.

std::string* name = new std::string ("Albert"), the value of *name is not displayed in the variables view.

Hey,
It's possible to add this into the plugin?

Which OS: Ubuntu 17.04
Which LLDB version (lldb -version): 4.0.0
Which VSCode version (Help/About): 1.12.2

What is the problem and how did you get there:

Traceback (most recent call last):
  File "/home/daniel/.vscode/extensions/vadimcn.vscode-lldb-0.5.0/adapter/formatters/rust.py", line 179, in get_vector_summary
    length = StdVectorSynthProvider(valobj.GetNonSyntheticValue()).len
TypeError: __init__() takes exactly 3 arguments (2 given)

Happens when unfolding a struct in the Local Variables view that contains a std::vec::Vec. Debugging seems to work regardless though.

What did you expect to have happened instead (if not obvious):
No uncaught exception

Which OS: Arch Linux
Which LLDB version (lldb -version): 3.9.1
Which VSCode version (Help/About): 1.10.2

What is the problem and how did you get there:
Cargo hello_world
Changed code to:

fn main() {
    println!("Hello, world!");
    println!("tes");
    let mut ten = 10;
    ten += 10;
    for _ in 0..ten {
        if ten % 2 == 0 {
            ten+=1
        }
    }
}

{
	"version": "0.2.0",
	"configurations": [
		{
			"type": "lldb",
			"request": "launch",
			"name": "Debug",
			"program": "${workspaceRoot}/target/debug/hello_world",
			"args": [],
			"cwd": "${workspaceRoot}"
		}
	]
}

Set breakpoint line at 2.
run debug hit next until the error

Error:
Unable to open 'range.rs': File not found (/checkout/src/libcore/iter/range.rs).
It should be looking in the set "rust.rustLangSrcPath": "/home/host/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src",

note:
sudo ln -s /home/user/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/ /checkout fixed this issue for me.

Hi,

On Mac OSX (and probably on other system) breakpoints do not get set (grayed in the IDE). I found the problem is that lldb (maybe) wants only the filename and not the full path for the function BreakpointCreateByLocation. It looks like (I've not tested it) that the problem show up when the "cwd": attribute is set in the launch.json (As was in my case).

I solved with the following in debugsession.py (line 169):

was:

file = str(source['path'])

changed to:

file = os.path.basename(str(source['path']))

This made my projects works.

Thanks for your great extension.

Carlo Lanzotti

Which OS: Linux
Which LLDB version (lldb -version): 4.0
Which VSCode version (Help/About): 1.12.2

What is the problem and how did you get there: Cannot load .lldbinit

What did you expect to have happened instead (if not obvious):

details:
I have a .lldbinit in home/xxxx dir. It has settings set target.load-cwd-lldbinit true.And I have a .lldbinit in my workspaceRoot.But when I run debug, I cannot use the custom commands defined in my workspaceRoot .lldbinit.

Which OS: Sierra 10.12
Which LLDB version (lldb -version): lldb-360.1.65
Which VSCode version (Help/About): Version 1.8.1

What is the problem and how did you get there:
Compiling C++ and linking with the -m32 flag to enforce strict C Struct padding for i386 targets. The workaround is to remove the -m32 flag, however; the C Structs padding are increased for x64 targets. It appears the plugin is defaulting to x64. The lldb works in the terminal for i386 targets.

What did you expect to have happened instead (if not obvious):
Error: Could not initialize debug target: the specified architecture 'x86_64-apple-macosx' is not compatible with 'i386-apple-macosx' in 'target-i386-macos-exe'

Which OS: Any
Which LLDB version (lldb -version): 0.4.1
Which VSCode version (Help/About): 0.11 insider

What is the problem and how did you get there:

The file name of executable has a hash tag suffix, so it can not be assigned in launch.json easily.

What did you expect to have happened instead (if not obvious):

At the end of the first line in section troubleshooting#Filing bugs
I think, maybe:

GitHib tracker -> GitHub tracker

this is my launch.json config

{
"version": "0.2.0",
"configurations": [
{
"name": "Firefox/LLDB",
"type": "lldb",
"request": "launch",
"program": "/Users/jyavenard/Work/Mozilla/obj-ff-dbg/dist/NightlyDebug.app/Contents/MacOS/firefox",
"args": ["-no-remote", "-foreground", "-p", "Development"],
"stopAtEntry": false,
"cwd": "${workspaceRoot}/../obj-ff-dbg/dist/bin",
"initCommands" : [ ],
"stdio" : "*",
"env": {
"DYLD_LIBRARY_PATH" : ".:./plugins:/Users/jyavenard/Work/mythtv/ffmpeg/build31/lib/",
"LIBRARY_PATH" : ".:./components",
"MOZ_XRE_DIR" : "${workspaceRoot}/../obj-ff-dbg/dist/bin",
"MOZ_LOG" : "MediaSource:5,MediaSourceSamples:5"
//"MOZ_LOG" : "MediaFormatReader:5,PlatformDecoderModule:5",
}
}
]
}

When starting the debugger, a new terminal is opened as expected.
it shows:
Last login: Thu Sep 22 20:51:05 on ttys003
jyapro:~ jyavenard$ arch -arch x86_64 '/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Resources/darwin-debug' --unix-socket=/tmp/WRDR8l --arch=x86_64 --working-dir '/Users/jyavenard/Work/Mozilla/mozilla-central/../obj-ff-dbg/dist/bin' --env='DYLD_LIBRARY_PATH=.:./plugins:/Users/jyavenard/Work/mythtv/ffmpeg/build31/lib/' --env='MOZ_XRE_DIR=/Users/jyavenard/Work/Mozilla/mozilla-central/../obj-ff-dbg/dist/bin' --env='LIBRARY_PATH=.:./components' --env='MOZ_LOG=MediaSource:5,MediaSourceSamples:5' --env='OS_ACTIVITY_DT_MODE=enable' -- '/Users/jyavenard/Work/Mozilla/obj-ff-dbg/dist/NightlyDebug.app/Contents/MacOS/firefox' '-no-remote' '-foreground' '-p' 'Development' ; echo Process exited with status $? ; exit

Launching: '/Users/jyavenard/Work/Mozilla/obj-ff-dbg/dist/NightlyDebug.app/Contents/MacOS/firefox'
Working directory: '/Users/jyavenard/Work/Mozilla/mozilla-central/../obj-ff-dbg/dist/bin'
5 arguments:
argv[0] = '/Users/jyavenard/Work/Mozilla/obj-ff-dbg/dist/NightlyDebug.app/Contents/MacOS/firefox'
argv[1] = '-no-remote'
argv[2] = '-foreground'
argv[3] = '-p'
argv[4] = 'Development'

And nothing else occurs...

Was working all fine before upgrading.

This is using macOS Sierra 10.12.

I've gotten LLDB to work via console. I'm able to set breakpoints and step through code... However, when using the LLDB Debugger Plugin in Visual Studio Code... I get this error message...

Error Debug adapter process has terminated unexpectedly

I wasn't able to find any log files. Here is my setup in VSCODE.

OS - Fedora 25

[michael@localhost ~]$ sudo dnf install python-lldb
Last metadata expiration check: 1:39:28 ago on Fri Mar 17 22:55:40 2017. Package python-lldb-3.9.1-1.fc25.x86_64 is already installed, skipping. Dependencies resolved. Nothing to do. Complete!

[michael@localhost ~]$ lldb --version
lldb version 3.9.1 ( revision )

Python 3.5.2
Python 2.7.13

[michael@localhost ~]$ code --version
1.10.2

Launch.json

[michael@localhost hello_rust]$ cat .vscode/launch.json  {
    "version": "0.2.0",
    "configurations": [
    {
        "name": "Launch",
        "type": "lldb",
        "request": "launch",
        "sourceLanguages": ["rust"],
        "stdio": [null, null, "/home/michael/my.log"],
        "program": "/home/michael/dev/hello_rust/target/debug/hello_rust",
        "cwd": "/home/michael/dev/hello_rust"
        }
    ] }

Settings.json

[michael@localhost hello_rust]$ cat .vscode/settings.json  
// Place your settings in this file to overwrite default and user settings.  
{
    "lldb.executable": "lldb",
    "lldb.log": "/home/michael/lldb.log"   
}

LLDB seems to be working

(lldb) target create /home/michael/dev/hello_rust/target/debug/hello_rust Current executable set to '/home/michael/dev/hello_rust/target/debug/hello_rust' (x86_64).

(lldb) breakpoint set --file main.rs --line 2 Breakpoint 1: where = hello_rust`hello_rust::main + 24 at main.rs:2, address = 0x00005555555599c8

(lldb) r Process 7862 launched: '/home/michael/dev/hello_rust/target/debug/hello_rust' (x86_64) Process 7862 stopped * thread #1: tid = 7862, 0x00005555555599c8 hello_rusthello_rust::main + 24 at main.rs:2, name = 'hello_rust',
  stop reason = breakpoint 1.1
      frame #0: 0x00005555555599c8 hello_rusthello_rust::main + 24 at main.rs:2 1 fn main() { -> 2 println!("Hello, world!"); 3 } 4

(lldb) n Hello, world!

I noticed this is not part of the documentation anymore, but the commit removing it doesn't mention why. Also, the launch.json in this repository still uses it. So has it been removed?

I'm not sure what changed but this had been working fine for quite some time. Then today whenever I try to start a debug session I get the error:

I enabled logging (per your instructions in another issue) but I don't see much useful info in there:

$> more vscode-lldb.log 
[15:06:14 main] Single-session mode on fds (3,4)
[15:06:14 protocolhandler] rx: {"type":"request","seq":1,"command":"initialize","arguments":{"adapterID":"lldb","pathFormat":"path","linesStartAt1":true,"columnsStartAt1":true,"supportsVariableType":true}}
[15:06:14 debugsession] ### Handling command: initialize
[15:06:14 debugsession] LLDB version: lldb-350.0.21.9
[15:06:14 protocolhandler] tx: {"request_seq": 1, "command": "initialize", "body": {"supportsConfigurationDoneRequest": true, "supportsFunctionBreakpoints": true, "supportsConditionalBreakpoints": true, "supportsEvaluateForHovers": true}, "type": "response", "success": true}
[15:06:14 protocolhandler] rx: {"type":"request","seq":2,"command":"launch","arguments":{"name":"Debug","type":"lldb","request":"launch","program":"/Users/xxxxx/xxxx/tzcode-latest/tz_experiments/tz_experiments","args":[]}}
[15:06:14 debugsession] ### Handling command: launch
[15:06:15 protocolhandler] tx: {"body": {}, "type": "event", "event": "initialized", "seq": 0}
[15:06:15 protocolhandler] rx: {"type":"request","seq":3,"command":"setFunctionBreakpoints","arguments":{"breakpoints":[]}}
[15:06:15 debugsession] ### Handling command: setFunctionBreakpoints
[15:06:15 protocolhandler] tx: {"request_seq": 3, "command": "setFunctionBreakpoints", "body": {"breakpoints": []}, "type": "response", "success": true}
[15:06:15 protocolhandler] rx: {"type":"request","seq":4,"command":"configurationDone"}
[15:06:15 debugsession] ### Handling command: configurationDone
[15:06:15 protocolhandler] tx: {"request_seq": 2, "command": "launch", "body": null, "type": "response", "success": true}
[15:06:15 debugevents] ### Debug event: Process::ProcessEventData 0x7fbc1dd025f0 Event: broadcaster = 0x7fbc1cb6c838 (lldb.process), type = 0x00000001 (state-changed), data = { process = 0x7fbc1cb6c800 (pid = 76482), state = running}
[15:06:15 protocolhandler] tx: {"request_seq": 4, "command": "configurationDone", "body": null, "type": "response", "success": true}
[15:06:15 debugevents] ### Debug event: Process::ProcessEventData 0x7fbc1d8153a0 Event: broadcaster = 0x7fbc1cb6c838 (lldb.process), type = 0x00000004 (stdout-available), data = { process = 0x7fbc1cb6c800 (pid = 76482), state = running}
[15:06:15 debugevents] ### Debug event: Process::ProcessEventData 0x7fbc1bc249f0 Event: broadcaster = 0x7fbc1cb6c838 (lldb.process), type = 0x00000004 (stdout-available), data = { process = 0x7fbc1cb6c800 (pid = 76482), state = running}
[15:06:15 debugevents] ### Debug event: Process::ProcessEventData 0x7fbc1bf6a5a0 Event: broadcaster = 0x7fbc1cb6c838 (lldb.process), type = 0x00000004 (stdout-available), data = { process = 0x7fbc1cb6c800 (pid = 76482), state = running}
[15:06:15 debugevents] ### Debug event: Process::ProcessEventData 0x7fbc1db00290 Event: broadcaster = 0x7fbc1cb6c838 (lldb.process), type = 0x00000001 (state-changed), data = { process = 0x7fbc1cb6c800 (pid = 76482), state = exited}

I'm on OSX and using:

Suggestions?

Which OS: MacOS 10.2.3
Which LLDB version (lldb -version): lldb-370.0.37
Which VSCode version (Help/About): 1.10.2

What is the problem and how did you get there: Starting the debugger always abort and the message "Debug adapter process has terminated unexpectedly" is shown at the time

$ lldb --version
lldb-370.0.37
Swift-3.1
jyapro:mozilla-central jyavenard$ lldb
There is a .lldbinit file in the current directory which is not being read.
To silence this warning without sourcing in the local .lldbinit,
add the following to the lldbinit file in your home directory:
settings set target.load-cwd-lldbinit false
To allow lldb to source .lldbinit files in the current working directory,
set the value of this variable to true. Only do so if you understand and
accept the security risk.
(lldb) script import sys, lldb
(lldb) script sys.version
'2.7.10 (default, Feb 6 2017, 23:53:20) \n[GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.34)]'
(lldb) script lldb.debugger.GetVersionString()
'lldb-370.0.37\n Swift-3.1'
(lldb)

From the lldb server console:
lldb -b -O "command script import '/Users/jyavenard/.vscode/extensions/vadimcn.v
scode-lldb-0.4.0/adapter'" -O "script adapter.main.run_tcp_server(ext_channel_po
rt=61912)"
bash-3.2$ lldb -b -O "command script import '/Users/jyavenard/.vscode/extensions
/vadimcn.vscode-lldb-0.4.0/adapter'" -O "script adapter.main.run_tcp_server(ext_
channel_port=61912)"
There is a .lldbinit file in the current directory which is not being read.
To silence this warning without sourcing in the local .lldbinit,
add the following to the lldbinit file in your home directory:
settings set target.load-cwd-lldbinit false
To allow lldb to source .lldbinit files in the current working directory,
set the value of this variable to true. Only do so if you understand and
accept the security risk.
(lldb) command script import '/Users/jyavenard/.vscode/extensions/vadimcn.vscode
-lldb-0.4.0/adapter'
(lldb) script adapter.main.run_tcp_server(ext_channel_port=61912)
[17:15:02 main] Server mode on port 4711 (Ctrl-C to stop)

it doesn't even appear to start there.

Windows 10 x64
lldb version 5.0.0
VSCode 1.11.2

Few mentions first.
LLVM 4.0 doesnt include lldb, so it's only possible to use LLVM from svn trunk (5+).
LLVM requires certain python distro (easly downgradable with conda).
lldb cannot debug another architecture (at least on Windows), so if you're insisting to use x86 version of LLVM (and so Python), would be good to say that people need to use i686 Rust toolchains as well.

Also your instruction missing that LLVM requires PYTHON_HOME to be set, like this:
PYTHON_HOME=C:\ProgramData\Anaconda3
This env variable eliminates segfault during lldb's script call.

Still, I have errors I cannot solve, and I'm not sure if it's lldb incompleteness, or rather myself.
After manipulation I've described, this is what lldb responds:

> lldb
(lldb) script
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "C:/Program Files (x86)/LLVM/lib/site-packages\lldb\embedded_interpreter.py", line 21, in <module>
    if 'libedit' in readline.__doc__:
TypeError: argument of type 'NoneType' is not iterable
Traceback (most recent call last):
  File "<string>", line 1, in <module>
NameError: name 'run_one_line' is not defined
Traceback (most recent call last):
  File "<string>", line 1, in <module>
NameError: name 'run_one_line' is not defined
Traceback (most recent call last):
  File "<string>", line 1, in <module>
NameError: name 'run_one_line' is not defined
Traceback (most recent call last):
  File "<string>", line 1, in <module>
NameError: name 'run_one_line' is not defined
Traceback (most recent call last):
  File "<string>", line 1, in <module>
NameError: name 'run_one_line' is not defined
Traceback (most recent call last):
  File "<string>", line 1, in <module>
NameError: name 'run_one_line' is not defined
Traceback (most recent call last):
  File "<string>", line 1, in <module>
NameError: name 'run_python_interpreter' is not defined

Google gives me Linux/MacOS questions, saying it's about another python version, but I have none: python3 is the only one python I have. Any ideas what else can be done?

Which OS: OSX
Which LLDB version (lldb -version): lldb-360.1.70
Which VSCode version (Help/About): version 1.13.1

What is the problem and how did you get there:

"args": ["Farbfüllung", "äöüßÄÖÜ"]

Passing over program debug arguments with umlauts etc. like e.g. "Farbfüllung" "äöüßÄÖÜ" will stop debugsession.py to work!

FIX: set python's default encoding to UTF-8 for the imported sys modul!

...
import sys
...
reload(sys)
sys.setdefaultencoding('utf-8')
...

What did you expect to have happened instead (if not obvious):

That it works with passing over Umlauts in arguments too!

Which OS: Mac OSX Sierra
Which LLDB version (lldb -version): lldb-370.0.37, Swift-3.1
Which VSCode version (Help/About): Version 1.11.1 (1.11.1)

What is the problem and how did you get there:
In the trouble shooting section the instruction to fix _io errors:

Create a script (e.g. my_lldb) with the following contents and mark it as executable (chmod a+x my_lldb):
#!/bin/sh
export PATH=/usr/bin:$PATH
exec lldb "$@"
Add "lldb.executable": "/path/to/my_lldb" in VSCode preferences.

I did as instructed however this does not solve the launch issue because in the launch server code you were using the wrong config. The current code look like this

function launchDebugServer(context) {
    return __awaiter(this, void 0, void 0, function* () {
        let port = yield ec.startListener();
        let config = vscode_1.workspace.getConfiguration('lldb');
        **let lldbPath = config.get('path', 'lldb');**
        let terminal = vscode_1.window.createTerminal('LLDB Debug Server');
        let adapterPath = path.join(context.extensionPath, 'adapter');
        **let command = util_1.format('lldb -b -O "command script import \'%s\'" ', adapterPath) +
            util_1.format('-O "script adapter.main.run_tcp_server(ext_channel_port=%d)"\n', port);**
        terminal.sendText(command);
    });
}

It should be this:

    return __awaiter(this, void 0, void 0, function* () {
        let port = yield ec.startListener();
        let config = vscode_1.workspace.getConfiguration('lldb');
        **let lldbExecutable = config.get('executable', 'lldb');**
        let terminal = vscode_1.window.createTerminal('LLDB Debug Server');
        let adapterPath = path.join(context.extensionPath, 'adapter');
        **let command = util_1.format('%s -b -O "command script import \'%s\'" ',lldbExecutable, adapterPath) +
            util_1.format('-O "script adapter.main.run_tcp_server(ext_channel_port=%d)"\n', port);**
        terminal.sendText(command);
    });
}

Which OS: Lubuntu 16.04.2
Which LLDB version (lldb -version): 3.8.0 (started in a shell. I don't know if that's also the one used in VS Code)
Which VSCode version (Help/About): 1.10.1

What is the problem and how did you get there:

I try to achieve what I do in QtCreator: Start debugging an external application by monitoring and waiting until my executable is touched.

I develop a ROS nodelet. To run it, I use rosrun but that translates to a call to nodelet with arguments. In a shell it looks like this call:
/opt/ros/kinetic/lib/nodelet/nodelet standalone myNode/SpecialNodelet
So, I execute the nodelet executable from ROS which in turn calls my nodelet that exists as an .so library file:
/home/me/path/to/myNodelet.so

I don't succeed to configure the debugger such that the command
/opt/ros/kinetic/lib/nodelet/nodelet standalone myNodelet/SpecialNodelet
is executed and that the debugger kicks in as soon as code from
/home/me/path/to/myNodelet.so
is executed. With QtCreator I had to monitor the nodelet executable from ROS.

I tried in launch.json:

        {
            "type": "lldb",
            "request": "custom",
            "name": "LLDB Custom launch",
            "initCommands": [
               "target create /home/me/path/to/myNodelet.so"
               // "target create /opt/ros/kinetic/lib/nodelet/nodelet"  // seems to succeed but exits immediately with return code 255 which is the same code as if calling it without arguments what seems to happen here
            ],
            "preRunCommands": [
                "run /opt/ros/kinetic/lib/nodelet/nodelet standalone myNode/SpecialNodelet"
                //"process attach --name myNodelet.so --waitfor"
                //"process attach --name nodelet --waitfor"
                
            ]
        }

So far it seems as if I succeed halfway as the output is:

Current executable set to '/home/me/path/to/myNodelet.so' (x86_64).
Process 8090 launched: '/home/me/path/to/myNodelet.so' (x86_64).
Internal debugger error:
Traceback (most recent call last):
  File "./adapter/debugsession.py", line 795, in handle_message
    result = handler(args)
  File "./adapter/debugsession.py", line 476, in DEBUG_stackTrace
    dasm = disassembly.Disassembly(pc_sbaddr, self.target)
  File "./adapter/disassembly.py", line 62, in __init__
    last_instr = self.instructions[len(self.instructions)-1]
  File "/usr/lib/python2.7/dist-packages/lldb/__init__.py", line 7149, in __getitem__
    return self.GetInstructionAtIndex(key)
  File "/usr/lib/python2.7/dist-packages/lldb/__init__.py", line 7112, in GetInstructionAtIndex
    return _lldb.SBInstructionList_GetInstructionAtIndex(self, idx)
OverflowError: in method 'SBInstructionList_GetInstructionAtIndex', argument 2 of type 'uint32_t'

As debugsession.py belongs to this extension, I think this could be a bug that belongs to this issue tracker here.

Or am I using the extension wrongly? Then please tell me how to do debugging this library given the invocation above.

Best
llvm

It doesn't appear that it's possible to set environment variables.

Having a environment entry that takes a dictionary of name/values like the default mi debugger would be great:

e.g.

            "environment": [
                { "name" : "DYLD_LIBRARY_PATH", "value" : ".:./plugins" },
                { "name" : "LIBRARY_PATH", "value" : ".:./components" },
            ],

Which OS: Windows 10
Which LLDB version (lldb -version): lldb version 5.0.0
Which VSCode version (Help/About): 1.11.0 insider

What is the problem and how did you get there:
I'm trying to debug a rust program.
It works fine, as long as I don't have any breakpoints.

But once I add a breakpoint in my program, lldb seems to crash.

All steps in the troubleshooting guide work just fine.

Debug Server output:

>> lldb -b -O "command script import 'C:\Users\johnb\.vscode-insiders\extensions\vadimcn.vscode-lldb-0.4.0\adapter'" -O "script adapter.main.run_tcp_server(ext
_channel_port=57152)"
(lldb) command script import 'C:\Users\johnb\.vscode-insiders\extensions\vadimcn.vscode-lldb-0.4.0\adapter'
(lldb) script adapter.main.run_tcp_server(ext_channel_port=57152)
[09:13:54 main] Server mode on port 4711 (Ctrl-C to stop)
[09:13:58 main] New connection from ('127.0.0.1', 57154)
[09:13:58 debugsession] Imported
[09:13:58 wireprotocol] rx: {"command":"initialize","arguments":{"clientID":"vscode","adapterID":"lldb","pathFormat":"path","linesStartAt1":true,"columnsStartA
t1":true,"supportsVariableType":true,"supportsVariablePaging":true,"supportsRunInTerminalRequest":true},"type":"request","seq":1}
[09:13:58 debugsession] ### Handling command: initialize
[09:13:58 debugsession] LLDB version: lldb version 5.0.0
[09:13:58 wireprotocol] tx: {"command":"initialize","type":"response","request_seq":1,"body":{"supportsConfigurationDoneRequest":true,"supportsConditionalBreak
points":true,"supportsEvaluateForHovers":true,"supportsFunctionBreakpoints":true,"supportsHitConditionalBreakpoints":true,"supportsSetVariable":true,"supportsC
ompletionsRequest":true},"success":true}
[09:13:58 wireprotocol] rx: {"command":"launch","arguments":{"type":"lldb","request":"launch","name":"Debug","sourceLanguages":["rust"],"program":"d:\\dev\\rus
t\\projects\\hello/target/debug/hello.exe","debugServer":4711},"type":"request","seq":2}
[09:13:58 debugsession] ### Handling command: launch
[09:13:58 wireprotocol] tx: {"seq":0,"type":"event","body":{},"event":"initialized"}
[09:13:58 wireprotocol] rx: {"command":"setBreakpoints","arguments":{"source":{"path":"d:\\dev\\rust\\projects\\hello\\src\\main.rs"},"lines":[6],"breakpoints"
:[{"line":6}],"sourceModified":false},"type":"request","seq":3}
[09:13:58 debugsession] ### Handling command: setBreakpoints
[09:13:58 debugevents] $$$ Debug event: Breakpoint::BreakpointEventData 0000022E181C96E0 Event: broadcaster = 0000022E17FF0CC0 (lldb.target), type = 0x00000001
 (breakpoint-changed), data = {}

Launch.json:

{
    "version": "0.2.0",
    "configurations": [
        {
            "type": "lldb",
            "request": "launch",
            "name": "Debug",
            "sourceLanguages": [
                "rust"
            ],
            "program": "${workspaceRoot}/target/debug/hello.exe",
            "debugServer": 4711
        }
    ]
}

The rust program:

fn sqr(x: f64) -> f64 {
    return x * x;
}

fn main() {
    let res = sqr(1.0);

    println!("square is {}", res);
}

LLVM crash:

Which OS: Ubuntu 16.10
Which LLDB version (lldb -version):

lldb version 4.0.0 ([email protected]:apple/swift-lldb.git revision e0208d67b0e643d2067964ebb510a0fb38536445)
 Swift-3.1 (revision 228feb1ee06152ec4ed1b3d6a497f92b172eaf67)
 clang revision a27f59eceefa3b4d60ab1133081662c4a25a43fb
 llvm revision a568eff4bfe5ff38a98bb1f8a00480449beec6ec

Which VSCode version (Help/About): 1.10.2

What is the problem and how did you get there:

• Install Swift 3.1 for Ubuntu 16.10
• Open a project generate with SwiftPM
• Put a breakpoint on Tests/ModuleName/UnitTest.swift
• Configure debug like this:

{"configurations": [
    {
        "type": "lldb",
        "request": "launch",
        "name": "Swift Test",
        "program": "/usr/bin/swift",
        "args": ["test"],
        "cwd": "${workspaceRoot}"
    }
]
}

• Start debugger
• Stop and display
  

What did you expect to have happened instead (if not obvious):

• Display Swift source where is the breakpoint

Debug session isn't starting after adding "env" parameter:

{
"version": "0.2.0",
"configurations": [
{
...
"env": {"SOME_VAR": "value"},
...
}
]
}

LLDB version: lldb-350.0.21.9 (also tested on lldb-340 with the same result)