Inspect Native Memory in Dart DevTools – Update and Follow-up on Pointer Inspection Enhancement.

[Shibam]

Hi Mentors,

I hope you are doing well.

I wanted to share my current progress and also follow up regarding the Pointer inspection enhancement in the Dart debugger. I would really appreciate your feedback whenever you have the time, as it will help me ensure I am proceeding in the right direction.

I’m excited to share a significant milestone in this work. Previously, Pointer instances appeared as opaque objects in the debugger (returned as "kind": "PlainInstance" with no accessible fields), providing no visibility into their underlying native memory. With recent modifications, I have enabled real memory address extraction at the VM/service level.

Specifically:

• Updated the VM service (getObject) handling for Pointer to expose the native address

• Ensured the address is correctly propagated through the service protocol as valueAsString

• Verified that the debugger/UI now displays actual memory addresses (e.g., ptr = 0x157508f6d20) instead of opaque placeholders

Additionally, I am now also able to observe the corresponding value during testing, which further validates that the pointer is correctly referencing accessible memory. I have also successfully displayed the native memory address in the Dart DevTools debugger.

This confirms that pointer detection, VM-level changes, service serialization, and UI representation are all functioning correctly.

For better understanding of the solution and for testing purposes, I have also implemented a proof-of-concept where I am effectively faking a transparent object for the debugger interface. By changing the JSON "kind" to "PlainInstance" and manually constructing a "fields" JSON array, I am representing the pointer as a normal Dart object with properties. This allows the debugger (VS Code/DevTools) to naturally parse and display it, enabling expansion of the pointer into fields like "address" and "value" directly in the variables tree.

What is currently missing to fully realize this approach safely and generically:

1. Safety:
   The current implementation uses direct memory access:
   int32_t value = *reinterpret_cast<int32_t*>(addr);
   This is unsafe, as it blindly dereferences the pointer when addr != 0. If the pointer is invalid, it can cause a VM crash (segfault). This needs to be replaced with a safe memory access mechanism such as OS::SafeRead.

2. Type Parsing:
   The implementation currently assumes an int32_t and labels the field as "value". This is not generic. For example, in Pointer<MyStruct>, it would incorrectly read only the first 4 bytes. A complete solution would dynamically inspect the Pointer<T> type, iterate through NativeStructType fields, and decode each field properly (e.g., int, double, etc.) with correct field names.

The goal is to allow the debugger to inspect memory contents at the pointer’s address and expose meaningful values, for example:

ptr = 0x157508f6d20

 └─ ref

      └─ value = 42

To achieve this, my planned approach is:

• Implement an OS::SafeRead(addr, buffer, size) function. On Windows, this will use ReadProcessMemory, and on Linux/macOS, it will use a system pipe-based technique to safely attempt memory reads. This ensures that accessing unmapped or invalid memory returns false instead of crashing the VM.

• Use the C++ FFI compiler classes (compiler::ffi::NativeType::FromAbstractType) to analyze Pointer<T>. This will allow extraction of the underlying type (e.g., MyStruct), querying exact byte offsets and sizes of fields (such as a, b), and safely reading memory using OS::SafeRead().

• Structure the JSON output exactly like the current prototype (kind: "PlainInstance" with a fields array), so that IDEs like VS Code and DevTools can naturally parse and expand the pointer as a tree structure in the variables panel.

Additionally, I would like to humbly mention that I have shared more detailed explanations and implementation notes in a separate email (to dacoh...@google.com and bko...@google.com), as I was not able to include everything here due to instructions. I kindly request you to please check that email as well for complete context.

I kindly request you to please review this approach and provide your feedback. Your guidance will help me move forward confidently.

Looking forward to your feedback.

Best regards,
Shibam Mandal