The editor doesn't handle correctly memory access errors

[AdrianOltean]

Description
Various memory areas in an embedded system can be inaccessible at some point, before an actual configuration/enablement. When Memory Inspector asks for memory to be read, the request eventually reaches a (GDB) debug server that might return a memory access error. Looks like Memory Inspector is not very good at handling such a situation and it simply reports "No results found".

How to reproduce:

1. NXP SDK, NXP LPC55S69 board, a J-Link debug probe. Should not matter as long as you can replicate what's written above.
2. MCUXpresso for VS Code extension installed.
3. Import a "Hello World" project using the MCUXpresso for VS Code extension.
4. Debug.
5. Start Memory Inspector and jump to address 0x20000000.
6. Load 128 more bytes above. At this point, address at 0x1FFFFF00 is inaccessible.

Or try to replicate the basic idea (assume some memory area is invalid and try to access it from Memory Inspector) by some other means, other setup.

Expected behavior
Memory Inspector should make it clear that memory cannot be accessed.

Environment

• OS: Windows 11
• Theia or VS Code Version: VS Code 1.96.4

Additional information

GDB debug server reports error but Memory Inspector simply shows "No results found":

[planger]

@AdrianOltean Thank you for pointing out this improvement! Are you interested in contributing a fix? I'd not expect this to be much work, but would have to reproduce this error locally to be sure. Thanks a lot in advance!

[AdrianOltean]

@planger You're probably right about the complexity of a potential fix... Hoping to have someone more familiar with the project to look into this.

[jreineckearm]

Thanks for raising this and other issues, @AdrianOltean !

Yes, the error handling in the Memory Inspector has room for improvement. I believe the error messages you show above point to failing readMemory requests.
There are a couple of aspects to this.

• We would need to check if we just throw an error if the memoryRequest fails. Or if we already check for partial read results.
• I believe we currently don't use the optional unreadableBytes field of ReadMemoryResponse.
• We may want to consider some fallback mechanisms to get as much information from the target memory as possible and piece things together.
• As always, the more the debug adapter supports of the DAP protocol, the more would be possible in the Memory Inspector.

A good entry point to understand how this currently works could be this search https://github.com/search?q=repo%3Aeclipse-cdt-cloud%2Fvscode-memory-inspector%20createMemoryFromRead&type=code