Address expression context only on top of stack

[lzace817]

Description

when using a expression as the address on the memory inspector, it will not work properly for previous stack frames.
How to reproduce:

• use the sample code bellow

#include <stdio.h>

static void foo(size_t val)
{
    printf("%ld\n", val*2); // <------------ break here
}

static void test(int n)
{
    foo(80*n);
}

int main(void)
{
    test(1);
    test(2);
    return 0;
}

• set break point at the comment
• run in debug
• select test on the call stack
• inspect the memory with expression &(n)
• Error message: No symbol "n" in current context.

Expected behavior

it should be able to get the adress of the local variable with no errors.

Environment

• OS: Ubuntu GNU/Linux
• Browser:
• Theia or VS Code Version:
  Version: 1.100.23258
  Commit: 557d9224936804f4aeb93625d7a45c97113627e4
  Date: 2025-05-15T18:24:48.143Z
  Electron: 34.5.4
  ElectronBuildId: undefined
  Chromium: 132.0.6834.210
  Node.js: 20.19.0
  V8: 13.2.152.41-electron.0
  OS: Linux x64 6.8.0-60-generic snap

Additional information

[jreineckearm]

Thanks for raising this, @lzace817 .

Could you please check if the variable n is stored in memory at all? Depending on used compiler toolchains, settings, complexity of your program, and possibly also target architecture, it can happen that local variables are never stored in memory but reside in CPU registers.

We could review if we can somehow improve the error handling/messaging. If that is the root cause for the problem you see.

[lzace817]

I can still repoduce it as long as I don't use any optmizations:

gcc -Wall -Wextra -Wpedantic -Wstrict-pro
totypes -Wswitch-enum -ggdb sample.c -o sam
ple

On the debug console: &n -> 0x7fffffffd13c, so the address exists.
If I optmize even for debug -Og, it ends up mapped to a register, as you predicted.
But the point is that it fails on any local variable not in the top of the stack. We don't need to use the sample code.

[jreineckearm]

Thanks for confirming, @lzace817 .

I was able to reproduce it here as well. Unfortunately, I am away now for a couple of days. So, this unfortunately has to wait unless someone else can further investigate what's causing this.

My next step would be to debug into it and to check if we receive all expected scopes requests here:

vscode-memory-inspector/src/plugin/adapter-registry/adapter-capabilities.ts

Line 69 in cbfcb9e

this.currentFrame = message.arguments.frameId;

And if we correctly trigger window refreshes based on this. This is where we capture the currently selected frame ID.

I also believe, that the VS Code API added in the meanwhile an alternative way to determine the currently focused stack frame. See activeStackItem here: https://code.visualstudio.com/api/references/vscode-api#debug