VSCode does not hit breakpoints when source path contains symlinks.

[Simsys]

Which OS: Linux Kubuntu 18.10
Which extension version: 1.1.2
Which LLDB version: 7.0
Which VSCode version: 1.29.1

What is the problem and how did you get there:
The program does not stop at breakpoints. It runs to the end without stopping. If I use the lldb debugger directly, it works as expected.

Output lldb

{ type: 'lldb',
  request: 'launch',
  name: 'Debug',
  program: '${workspaceRoot}/target/debug/read_phonebook',
  args: [ './data/contacts.csv' ],
  cwd: '${workspaceRoot}' }
(lldb) command script import '/home/winni/.vscode/extensions/vadimcn.vscode-lldb-1.1.2/adapter'
bind: Invalid command `enable-meta-key'.
(lldb) script adapter.run_tcp_session(0, 'eyJzb3VyY2VMYW5ndWFnZXMiOlsicnVzdCJdfQ==')
Listening on port 37187

Output F1/LLDB: run diagnostics

lldb version 7.0.0
--- Checking Python ---
(lldb) script import sys, io, lldb
bind: Invalid command `enable-meta-key'.
(lldb) script print(lldb.SBDebugger.Create().IsValid())
True
(lldb) script print("OK")
OK
--- Done ---

Output, when I use LLDB via command line

lldb version 7.0.0
(lldb) script import sys, io, lldb
(lldb) script print(lldb.SBDebugger.Create().IsValid())
True
(lldb) script print("OK")
OK

Workspace Settings:

"lldb.logLevel": 0

What did you expect to have happened instead:
The program stops at breakpoints

[vadimcn]

Hmm, sorry, no idea what's going on.
One thing to try would be to add "stopOnEntry": true to the launch config, and when debugger stops (assuming it does), try to examine process state through lldb commands (e.g. see if break set ... works, whether symbols are loaded, etc).

[Simsys]

It stops!

Mainwindow:

; id = {0x00000176}, range = [0x0000000000001090-0x0000000000001098), name="_start"
; Source location: unknown
7FFFF7FD4090: 48 89 E7                   movq   %rsp, %rdi
7FFFF7FD4093: E8 98 0F 00 00             callq  0x7ffff7fd5030  ; _dl_start at rtld.c:445

Debug console:

Current breakpoints:
1: file = '/home/winni/working_copy/working_copy/hacking/rust/read_phonebook/src/main.rs', line = 12, exact_match = 0, locations = 0 (pending)
    Breakpoint commands (Python):
      return adapter.debugsession.on_breakpoint_hit(frame, bp_loc, internal_dict)

2: name = 'rust_panic', locations = 1, resolved = 1, hit count = 0
  2.1: where = read_phonebook`rust_panic + 19 at panicking.rs:525, address = 0x000055555558d863, resolved, hit count = 0

F5 runs to the end without stopping

[vadimcn]

If you run image dump line-table main.rs, do you get any entries for main.rs:12?
What is the path prefix of source files? Is it /home/winni/working_copy/working_copy/hacking/rust/read_phonebook/src ?

[Simsys]

My debugger now works as expected. I copied the project into the home directory and everything works.

The problem seems to be that I had a symlink inside the path. Other development environments have no problem with this.

Many thanks for the support.

[vadimcn]

Okay, let's keep it open for now. Symlinks should have worked.

[Simsys]

I checked that again. I set a symlink on the same level and it didn't work again.

The symlink causes the problem

[CodeMouse92]

I seem to be having this issue as well (Ubuntu 18.04.2, LLDB 6.0, VS Code 1.31.1, CodeLLDB 1.2.1).

[Tinyik]

Hit this problem as well. (macOS 10.14.5, lldb-1001.0.1, VS Code 1.32.3, CodeLLDB 1.2.1).

After "break set", the breakpoint indeed shows up in "break list" (also in VSCode GUI, as a little red dot in line number gutter), but "continue" runs until program exits. I am using lldb "gdb-remote" for remote debugging. Running lldb in command line hits breakpoint as expected.

launch.json:

{
    "name": "LLDB",  
    "type": "lldb",  
    "request": "custom",
    "targetCreateCommands": ["target create debuggee.sys"],
    "processCreateCommands": ["gdb-remote 8000"]
}

The path for debuggee.sys contains symlinks.

[vadimcn]

@Simsys, @Tinyik, if you are still there: as I understand, the source location you've opened with VSCode was symlinked, right? But when you compiled the program, did you give compiler the symlinked or the original path?

[almindor]

I can confirm this issue as well.

I've recently symlinked my main programming folder and noticed this issue.

EDIT: to clarify, it works if I open the project folder from the absolute path, but fails if I open the project folder from the symlinked path. Might be a OSSCode/VSCode bug?

[vadimcn]

@almindor, are you debugging a Rust program? The problems seems to be in the Rust compiler: it seems to normalize source file paths before encoding them in the debug info. If I add "sourceMap": {"<original path>: "<symlinked path>"} into my launch config, breakpoints do work.

[almindor]

Ah that seems to be correct. I wonder if it can be considered a bug we should report upstream. Strictly speaking the debug info should have the "proper absolute path"

[gilescope]

Interestingly I hit a similar issue on win7/gnu. Had the code in c:\git\hello-world and had c:\git mapped to h:\ - if I try to debug from h: in vscode and cargo build it from c:\git\hello-world it skips all the breakpoints.

[ximon18]

I just hit this issue, took me quite a while to find this GH issue and final get it working!

FYI I am running Ubuntu 18.04 LTS, vscode-lldb 1.5.0 and vs code 1.45.1.

I have a sym link like so:

$ pwd
/home/ximon
ximon@ximon-laptop:~$ ls -la src
lrwxrwxrwx 1 ximon ximon 14 apr  6 10:04 src -> Documents/code

If I open my Rust program source directory in vs code via the sym link then LLDB with stop-on-entry true shows sourcel location unknown and is unable to set breakpoints via the point-n-click in the VS code window, but interesitngly setting a breakpoint via the debug console with command:

breakpoint set -f main.rs -l 27

Does work, does cause the breakpoint to appear in the "BREAKPOINTS" view in vs code but NOT in the gutter in main.rs in vs code.

Re-opening the program source directory without the sym link makes everything just work.

[vadimcn]

@ximon18 see this comment

[ximon18]

Thanks, I'll try that, apologies for not spotting that in the messages above!

[feldim2425]

Also ran into this problem since my folder for all my projects is symlinked to my second drive.
If anyone has a similar setup and therefore doesn't want to put the "sourceMap" into each individual launch config, creating a entry "lldb.launch.sourceMap" in your user configuration file for the symlinked projects folder also seems to work.
Example for my case:

"lldb.launch.sourceMap": {
    "<mountpoint>/projects": "/home/user/projects"
}

[winter233]

I have this problem too. I checked the 'breakpoint' request json, the path is real path, and the debug info record in the ELF is the symlink path. I think this is a lldb bug. An easy way to verify is, start lldb, executing b full_symlink_path:line_no and b full_real_path:line_no, it probably failed on the first. However, gdb can succeed on both command.

[vadimcn]

This is caused by the Rust compiler replacing symlinks with real paths in debug info. In order to use symlinks, you'll need set up a sourceMap.
See also: https://github.com/vadimcn/vscode-lldb/wiki/Breakpoints-are-not-getting-hit