Excluded Callers feature not working in Dev Container

[rjra100]

OS: Windows 10 21H2 + WSL + Docker running a RHEL7.9 container (sorry!) VSCode version: 1.79.2 + Dev Containers 0.295.0 CodeLLDB version: 1.9.2 (custom-built on RHEL7.9 because it's got an ancient glibc and the store version doesn't run, but no code changes) Compiler: gcc 10.2.1 (also tried with clang 15.0.7; identical behaviour) Debuggee: Any C++ binary

The new Excluded Callers feature sounds great, but I'm afraid it doesn't appear to be working in a dev container environment. Attempting to exclude any stack frame results in a popup "Could not locate symbol for this stack frame".

I reproduced with an example as simple as

void f() {
    int x = 0;    // breakpoint here
}
int main() { f(); return 0; }

g++ -g test.cpp, debug and attempt to exclude main().

Verbose logging doesn't appear to produce much of interest. However, lldb logging (log enable lldb break) produces this:

codelldb         0x5642ad5a08a0 Broadcaster("lldb.target")::BroadcastEvent (event_sp = {0x5642ac9f3170 Event: broadcaster = 0x5642ac8f93d8 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {bkpt: 22 type: breakpoint added}}, unique =0) hijack = (nil)
codelldb         Target::AddBreakpoint (internal = no) => break_id = 22: file = 'vscode-remote:/dev-container%2B7b22686f737450617468223a225c5c5c5c77736c245c5c5562756e74752d32302e30345c5c686f6d655c5c72616c6578616e64657237325c5c6769745c5c77735c5c7166645f7773222c22636f6e66696746696c65223a7b22246d6964223a312c2270617468223a222f686f6d652f72616c6578616e64657237322f6769742f77732f7166645f77732f2e646576636f6e7461696e65722f646576636f6e7461696e65722e6a736f6e222c22736368656d65223a227673636f64652d66696c65486f7374227d7d/workspaces/test.cpp', line = 4, column = 15, exact_match = 0
codelldb         removing not matching relative path /workspaces since it doesn't end with vscode-remote:/dev-container%2B7b22686f737450617468223a225c5c5c5c77736c245c5c5562756e74752d32302e30345c5c686f6d655c5c72616c6578616e64657237325c5c6769745c5c77735c5c7166645f7773222c22636f6e66696746696c65223a7b22246d6964223a312c2270617468223a222f686f6d652f72616c6578616e64657237322f6769742f77732f7166645f77732f2e646576636f6e7461696e65722f646576636f6e7461696e65722e6a736f6e222c22736368656d65223a227673636f64652d66696c65486f7374227d7d/workspaces
codelldb         Target::RemoveBreakpointByID (break_id = 22, internal = no)

From the looks of it, because I'm running in a containerised environment the file path is coming out with a vscode-remote:/\<blah> prefix on it, and as a result lldb's filtering it out and not resolving the breakpoint to any locations. I'm not entirely clear where the remote container prefix is coming from, though. A breakpoint is correctly created if I simply run break set -f /workspaces/test.cpp -l 4 -u 15 in the debug console (or in command line lldb), but I get similar behaviour if I include the vscode-remote prefix there.

Incidentally, I guess there was probably a reason, but from a quick look at the implementation of the exclude callers function I was a bit surprised to find that it involves the creation of temporary breakpoints in order to resolve symbols - the more obvious approach to me would seem to be to directly ask the lldb frame object for its symbol (via the Python interface, if you've got an SBFrame object you can do frame.GetSymbol() and go from there without needing to mess about with breakpoints at all). The ExcludeSymbolRequest seems to pass the file location rather than the frame, though, so perhaps that isn't an option.

Let me know if there's any way I can help debug this - I've got the containerised environment all set up and I'm also also set up to run custom builds of the extension if that'll help, so if you'd like me to add any logging or try out any experimental fixes, I'm very happy to do so.

[vadimcn]

I was a bit surprised to find that it involves the creation of temporary breakpoints in order to resolve symbols - the more obvious approach to me would seem to be to directly ask the lldb frame object for its symbol

Unfortunately VSCode does not expose stack frame ids to extensions, only their source locations.

[rjra100]

I've raised a PR with a fix that works for me.