Paths mismatch in clearBreakPoints

[abussy-aldebaran]

When called from setBreakPointsRequest, clearBreakPoints does a path comparison between local and remote paths. Thus breakpoints are never cleared.

[abussy-aldebaran]

I made a quick patch on my fork 9df4fae, for both this issue and #381

[brownts]

Hi @abussy-aldebaran, from your patch it appears you are using this with an SSH connection. The extension attempts to determine the OS of the remote system based on the path mappings, but it is not aware of what it is. Thus, it will look at the path mappings and try to determine if they are POSIX or Win32 paths. Since Win32 paths can be specified with both / and \, this makes it more difficult. One of the checks it will perform is to try and determine if it is an absolute path for Win32 or POSIX. If it can determine that the path mapping is an absolute path, it will use it and the ambiguity is resolved, otherwise it doesn't know and attempts to guess.

What do the path mappings look like in your configuration? If they are relative paths, can you try changing them to absolute paths and see if this fixes the issue?

[abussy-aldebaran]

Hi ! The path mappings are relative in my configuration. With absolute paths, detection of OS works correctly, but breakpoints don't.
I used relative paths because, when pausing while my code is executed, the stacktrace shows relative paths. These paths are written in the binary by the compile right ? I guess that's why absolute paths won't work.
However I found a way to make absolute paths work but there's a catch. Suppose my project structure is:

my-project/
  |-- my-exe/
    |-- main.cpp
  |-- my-lib/
    |-- src/
      |-- hello.cpp

and is installed in the folder /src on remote. In the stacktrace cpp files are referenced as ../my-exe/main.cpp and ../src/hello.cpp. Here's how the configuration would look like:

"ssh": {
  "cwd": "/src/my-project/my-exe",
  "sourceFileMap": {
    "/src/my-project/my-exe": "${workspaceRoot}/my-exe",
    "/src/my-project/my-lib/src": "${workspaceRoot}/my-project/my-lib/src",
  },
}

Breakpoints will work in main.cpp but not in hello.cpp. I think this is because
"sourceFileMap"."/src/my-project/my-exe"/main.cpp = "cwd"/../my-exe/main.cpp
whereas
"sourceFileMap"."/src/my-project/my-lib/src"/hello.cpp != "cwd"/../src/hello.cpp

Maybe OS detection could be manually overridden with a parameter ?

Nevertheless, it has no impact on the comparison of source and index.file in clearBreakPoints. The former is a local path, and the latter is a remote path.

[brownts]

I don't believe you should need to specify absolute paths on the local side, only the remote. The extension is able to determine the system it is running on, just not the remote system. Therefore, try using relative paths for the local paths but absolute paths for the remote path, in the path mapping.

Additionally, if you want, it is possible to force absolute paths in your debug information using -fdebug-prefix-map, although I don't think that is required in this case.

If possible, can you include the log output for the problem where you enable showDevDebugOutput in your configuration?

[abussy-aldebaran]

I can't include the log output since it's company code, and I could not produce a MRE. I added the parameter ssh.pathKind in my fork, and I can do a PR if that's ok with you.

Concerning the setBreakPointsRequest bug, is there a reason why clearBreakPoints is passed a local path, whereas addBreakPoint is passed a remote path ?

[brownts]

Adding ssh.pathKind might be an option, but I wonder if we could use the ssh.cwd instead. I believe that is a required field, and I'd assume it would be an absolute path. Do you have that specified and is that an absolute path? If so, that might be the preferred solution rather than introducing another configuration parameter.

As for the setBreakPointsRequest, yes that looks like a bug. Please submit a PR with your fix. Thanks!

[GitMensch]

cwd should work five also with relative (to the workspace) paths, if absolute paths in there work for this scenario, while relative doesn't then it would be the extension configuration code which should make that path absolute first.

[abussy-aldebaran]

My ssh.cwd is an absolute path, so that would work in my case.

Another idea could be to send a uname through ssh, and fallback to win32 if it fails ?