[lldb] Don't use a vm addr range starting at 0 for local memory (#100288) #9187
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…#100288) When an inferior stub cannot allocate memory for lldb, and lldb needs to store the result of expressions, it will do it in lldb's own memory range ("host memory"). But it needs to find a virtual address range that is not used in the inferior process. It tries to use the qMemoryRegionInfo gdb remote serial protocol packet to find a range that is inaccessible, starting at address 0 and moving up the size of each region. If the first region found at address 0 is inaccessible, lldb will use the address range starting at 0 to mean "read lldb's host memory, not the process memory", and programs that crash with a null dereference will have poor behavior. This patch skips consideration of a memory region that starts at address 0. I also clarified the documentation of qMemoryRegionInfo to make it clear that the stub is required to provide permissions for a memory range that is accessable, it is not an optional key in this response. This issue was originally found by a stub that did not list permissions in its response, and lldb treated the first region returned as the one it would use. (the stub also didn't support the memory-allocate packet) (cherry picked from commit 2ba1aee)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When an inferior stub cannot allocate memory for lldb, and lldb needs to store the result of expressions, it will do it in lldb's own memory range ("host memory"). But it needs to find a virtual address range that is not used in the inferior process. It tries to use the qMemoryRegionInfo gdb remote serial protocol packet to find a range that is inaccessible, starting at address 0 and moving up the size of each region.
If the first region found at address 0 is inaccessible, lldb will use the address range starting at 0 to mean "read lldb's host memory, not the process memory", and programs that crash with a null dereference will have poor behavior.
This patch skips consideration of a memory region that starts at address 0.
I also clarified the documentation of qMemoryRegionInfo to make it clear that the stub is required to provide permissions for a memory range that is accessable, it is not an optional key in this response. This issue was originally found by a stub that did not list permissions in its response, and lldb treated the first region returned as the one it would use. (the stub also didn't support the memory-allocate packet)
(cherry picked from commit 2ba1aee)