[GSoC 2026] Native Memory Inspector- Questions about VM Service Protocol and Safe Memory Reading

[Gurleen Kaur]

Hi mentors,

I'm Gurleen, exploring the "Inspect Native Memory in Dart DevTools" project for GSoC 2026.

I've been studying the existing code and I have two technical questions:

1. VM Service Protocol for struct layout

Since Pointer<MyStruct> is erased to Pointer<Never> at runtime (as discussed in the recent thread), the type name would need to come from static analysis via DAP. My question is — is there currently any VM Service RPC that exposes FFI struct field annotations (offsets, sizes, types) for a given class, or would this project require adding a new protocol extension? I looked at runtime/vm/compiler/ffi/native_type.cc and can see the layout computation there but couldn't find an existing way to expose this over the protocol.

2. Safe memory reading for invalid pointers

For reading memory at a pointer address without crashing on invalid pointers — is sigaction on Linux/Mac and Structured Exception Handling on Windows the intended approach, or is there a different mechanism already used elsewhere in the VM that would be more appropriate to build on?

Thank you.

Gurleen-kansray

[Daco Harkes]

Hi Gurleen!

A reply to the public thread as well:

 

1. Since runtime type is erased, my understanding of the approach is: the DAP/IDE holds the static type from source analysis and passes the type name (MyStruct) to the VM, which looks up the class and reads its FFI field annotations from native_type.cc to compute offsets and sizes. Is this correct? Is there currently any VM Service RPC that exposes FFI struct layout for a given class, or would a new protocol extension need to be added?

There currently is not.

pkg/vm/lib/modular/transformations/ffi/definitions.dart creates <name>#offsetOff getters that compute the offset of a field in a struct. I am not sure if you'd be able to call those already right now. If that's not accessible, then we might indeed add a new protocol extension.

2. For safe memory reading to avoid SIGSEGV on invalid non-null pointers — is the plan to use sigaction on Linux/Mac and Structured Exception Handling on Windows to catch bad memory accesses and convert them into a structured error response, or is there a different mechanism you had in mind? 

Yes. I am not entirely sure how safe we can make it, technically catching those memory errors is undefined behavior. However, it's worth giving it a shot with the various mechanisms for the various OSes to see how far we can push it.

Happy hacking!

 •  Daco Harkes
 •  Software Engineer
 •  dacoh...@google.com 

On Mon, Feb 23, 2026 at 1:02 PM Gurleen Kaur <gurlee...@gmail.com> wrote:

Hi mentors,                                                                                                                                                                                                                                                                            I'm Gurleen, exploring the "Inspect Native Memory in Dart DevTools" project for GSoC 2026.I've been studying the existing code and I have two technical questions:

--
You received this message because you are subscribed to the Google Groups "dart-gsoc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dart-gsoc+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/dart-gsoc/febd2c79-1401-4080-8c5a-df60c62bc2aen%40googlegroups.com.

[Gurleen Kaur]

Hi Daco,

Thank you for pointing me to definitions.dart. I went through the complete file carefully and have some observations and follow-up questions.

1. I noticed that _annoteStructOrUnionWithFields() adds a @pragma('vm:ffi:struct-fields') annotation directly onto every struct class after transformation. This annotation contains the complete field type list as a ListConstant. The transformer itself reads this back via _compoundAnnotatedFields(), which suggests it is designed to be readable. Since pragma annotations on classes are accessible via getObject() in the VM Service Protocol, would reading this annotation be a better approach than calling #offsetOf getters? It seems like this could give us full field type information without needing to invoke any synthetic members at all.

2. I noticed that #offsetOf getters are explicitly marked isSynthetic = true, but #sizeOf is NOT marked synthetic — it only has isStatic: true. Does this mean #sizeOf is already callable via the expression evaluator while #offsetOf getters may not be accessible the same way?

3. Both getters use runtimeBranchOnLayout() which from the file comment generates code like int get #sizeOf => (const [24,24,16])[_abi()]. This means calling the getter at runtime automatically returns the correct value for the current platform — we would not need to manually determine the ABI separately. Is this understanding correct?

Thank you for your time again.

Gurleen-kansray

[Daco Harkes]

Hey Gurleen,

My hunch is that using the synthetic members would be easier, as you observe the abi() is automatic there. But I haven't fully thought it through. You can experiment and see.

#sizeOf is NOT marked synthetic

I think that is a bug. You can submit a CL to mark it synthetic! (See https://github.com/dart-lang/sdk/blob/main/CONTRIBUTING.md on how to make a Gerrit CL.)

Whether it's synthetic or not, should not affect whether it's callable.

Kind regards,

 •  Daco Harkes
 •  Software Engineer
 •  dacoh...@google.com 

To view this discussion visit https://groups.google.com/d/msgid/dart-gsoc/9e3a4e69-be0f-4580-9690-f97294fe9c52n%40googlegroups.com.

[Gurleen Kaur]

Hi Daco,

Thank you for the clarification, that's very helpful. I am glad the observation about #sizeOf was useful. I will look into submitting a CL to mark it synthetic as you suggested, and will also experiment with calling the synthetic members via the expression evaluator to better understand the implementation path.

Thank you for your time.

Gurleen

[Gurleen Kaur]

Hi Daco,

I submitted the fix to mark #sizeOf as synthetic here: https://dart-review.googlesource.com/c/sdk/+/483400

Please let me know if anything needs to be changed.

Gurleen-kansray

On Tuesday, 24 February 2026 at 12:55:02 UTC+5:30 dacoharkes wrote: