-
Notifications
You must be signed in to change notification settings - Fork 15.2k
[lldb] Handle an empty SBMemoryRegionInfo from scripted process #115963
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
jasonmolenda
merged 6 commits into
llvm:main
from
jasonmolenda:detect-empty-sbmemoryregioninfo-reponses
Nov 15, 2024
Merged
Changes from 1 commit
Commits
Show all changes
6 commits
Select commit
Hold shift + click to select a range
f8f1d70
[lldb] Handle an empty SBMemoryRegionInfo from scripted process
jasonmolenda 0e57707
Remove the clearly unnecessary parts from
jasonmolenda 403fe3d
Update patch to move the check for memory regions to
jasonmolenda aadf21d
Update error message.
jasonmolenda d4125c1
Change the test to be "returned region must contain addr"
jasonmolenda f79aa73
Ismail caught a logic error on my part, used a built-in method
jasonmolenda File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
3 changes: 3 additions & 0 deletions
3
lldb/test/API/functionalities/scripted_process_empty_memory_region/Makefile
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
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,3 @@ | ||
| C_SOURCES := main.c | ||
|
|
||
| include Makefile.rules |
33 changes: 33 additions & 0 deletions
33
...ctionalities/scripted_process_empty_memory_region/TestScriptedProcessEmptyMemoryRegion.py
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
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,33 @@ | ||
| """ | ||
| Test python scripted process which returns an empty SBMemoryRegionInfo | ||
| """ | ||
|
|
||
| import os, shutil | ||
|
|
||
| import lldb | ||
| from lldbsuite.test.decorators import * | ||
| from lldbsuite.test.lldbtest import * | ||
| from lldbsuite.test import lldbutil | ||
| from lldbsuite.test import lldbtest | ||
|
|
||
|
|
||
| class ScriptedProcessEmptyMemoryRegion(TestBase): | ||
| NO_DEBUG_INFO_TESTCASE = True | ||
|
|
||
| def test_scripted_process_empty_memory_region(self): | ||
| """Test that lldb handles an empty SBMemoryRegionInfo object from | ||
| a scripted process plugin.""" | ||
| self.build() | ||
|
|
||
| target = self.dbg.CreateTarget(self.getBuildArtifact("a.out")) | ||
| self.assertTrue(target, VALID_TARGET) | ||
|
|
||
| scripted_process_example_relpath = "dummy_scripted_process.py" | ||
| self.runCmd( | ||
| "command script import " | ||
| + os.path.join(self.getSourceDir(), scripted_process_example_relpath) | ||
| ) | ||
|
|
||
| self.expect("memory region 0", error=True, substrs=["Invalid memory region"]) | ||
|
|
||
| self.expect("expr -- 5", substrs=["5"]) |
137 changes: 137 additions & 0 deletions
137
lldb/test/API/functionalities/scripted_process_empty_memory_region/dummy_scripted_process.py
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
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,137 @@ | ||
| import os, struct, signal | ||
|
|
||
| from typing import Any, Dict | ||
|
|
||
| import lldb | ||
| from lldb.plugins.scripted_process import ScriptedProcess | ||
| from lldb.plugins.scripted_process import ScriptedThread | ||
|
|
||
|
|
||
| class DummyStopHook: | ||
| def __init__(self, target, args): | ||
| self.target = target | ||
| self.args = args | ||
|
|
||
| def handle_stop(self, exe_ctx, stream): | ||
| print("My DummyStopHook triggered. Printing args: \n%s" % self.args) | ||
| sp = exe_ctx.process.GetScriptedImplementation() | ||
| sp.handled_stop = True | ||
|
|
||
|
|
||
|
||
| class DummyScriptedProcess(ScriptedProcess): | ||
| memory = None | ||
|
|
||
| def __init__(self, exe_ctx: lldb.SBExecutionContext, args: lldb.SBStructuredData): | ||
| super().__init__(exe_ctx, args) | ||
| self.threads[0] = DummyScriptedThread(self, None) | ||
| self.memory = {} | ||
| addr = 0x500000000 | ||
| debugger = self.target.GetDebugger() | ||
| index = debugger.GetIndexOfTarget(self.target) | ||
| self.memory[addr] = "Hello, target " + str(index) | ||
| self.handled_stop = False | ||
|
|
||
| def read_memory_at_address( | ||
| self, addr: int, size: int, error: lldb.SBError | ||
| ) -> lldb.SBData: | ||
| data = lldb.SBData().CreateDataFromCString( | ||
| self.target.GetByteOrder(), self.target.GetCodeByteSize(), self.memory[addr] | ||
| ) | ||
|
|
||
| return data | ||
|
|
||
| def get_memory_region_containing_address( | ||
| self, addr: int | ||
| ) -> lldb.SBMemoryRegionInfo: | ||
| return lldb.SBMemoryRegionInfo() | ||
|
|
||
| def write_memory_at_address(self, addr, data, error): | ||
| self.memory[addr] = data.GetString(error, 0) | ||
| return len(self.memory[addr]) + 1 | ||
|
|
||
| def get_loaded_images(self): | ||
| return self.loaded_images | ||
|
|
||
| def get_process_id(self) -> int: | ||
| return 42 | ||
|
|
||
| def should_stop(self) -> bool: | ||
| return True | ||
|
|
||
| def is_alive(self) -> bool: | ||
| return True | ||
|
|
||
| def get_scripted_thread_plugin(self): | ||
| return DummyScriptedThread.__module__ + "." + DummyScriptedThread.__name__ | ||
|
|
||
| def my_super_secret_method(self): | ||
| if hasattr(self, "my_super_secret_member"): | ||
| return self.my_super_secret_member | ||
| else: | ||
| return None | ||
|
|
||
|
|
||
| class DummyScriptedThread(ScriptedThread): | ||
| def __init__(self, process, args): | ||
| super().__init__(process, args) | ||
| self.frames.append({"pc": 0x0100001B00}) | ||
|
|
||
| def get_thread_id(self) -> int: | ||
| return 0x19 | ||
|
|
||
| def get_name(self) -> str: | ||
| return DummyScriptedThread.__name__ + ".thread-1" | ||
|
|
||
| def get_state(self) -> int: | ||
| return lldb.eStateStopped | ||
|
|
||
| def get_stop_reason(self) -> Dict[str, Any]: | ||
| return {"type": lldb.eStopReasonTrace, "data": {}} | ||
|
|
||
| def get_register_context(self) -> str: | ||
| return struct.pack( | ||
| "21Q", | ||
| 1, | ||
| 2, | ||
| 3, | ||
| 4, | ||
| 5, | ||
| 6, | ||
| 7, | ||
| 8, | ||
| 9, | ||
| 10, | ||
| 11, | ||
| 12, | ||
| 13, | ||
| 14, | ||
| 15, | ||
| 16, | ||
| 17, | ||
| 18, | ||
| 19, | ||
| 20, | ||
| 21, | ||
| ) | ||
|
|
||
|
|
||
| def __lldb_init_module(debugger, dict): | ||
| # This is used when loading the script in an interactive debug session to | ||
| # automatically, register the stop-hook and launch the scripted process. | ||
| if not "SKIP_SCRIPTED_PROCESS_LAUNCH" in os.environ: | ||
| debugger.HandleCommand( | ||
| "target stop-hook add -k first -v 1 -k second -v 2 -P %s.%s" | ||
| % (__name__, DummyStopHook.__name__) | ||
| ) | ||
| debugger.HandleCommand( | ||
| "process launch -C %s.%s" % (__name__, DummyScriptedProcess.__name__) | ||
| ) | ||
| else: | ||
| print( | ||
| "Name of the class that will manage the scripted process: '%s.%s'" | ||
| % (__name__, DummyScriptedProcess.__name__) | ||
| ) | ||
| print( | ||
| "Name of the class that will manage the stop-hook: '%s.%s'" | ||
| % (__name__, DummyStopHook.__name__) | ||
| ) | ||
|
||
1 change: 1 addition & 0 deletions
1
lldb/test/API/functionalities/scripted_process_empty_memory_region/main.c
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
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1 @@ | ||
| int main() {} |
Oops, something went wrong.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why would the size be
LLDB_INVALID_ADDRESS? Did you mean to check that the range base isn'tLLDB_INVALID_ADDRESS?Is this the condition you want?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Last week I had another similar bug where a gdb remote stub was returning start addr 0 size UINT64_MAX as a region response, and I was trying to reject that in addition to addr 0 size 0. I haven't seen someone send that same incorrect response from a scripted process, though, I should just check for 0/0 here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not wedded to it. I'm still debating moving both of these checks up in to Process::GetMemoryRegionInfo. I haven't done it yet for fear of unintended consequences, but any memory region info response that claims 0 bytes or the entire address space is meaningless.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A single region that covers the entire address space is fairly boring, but it is the kind of thing I might return as an "I don't know" value (perhaps I'm in some embedded environment where every address really is readable?). What's the problem with that kind of result?
Also, I think this check could be made more robust.
(0, 0)is the likeliest response, but doesn't this mean that we would still loop if the plugin returns(0,1)instead? It sounds to me that if we check that:then we can guarantee forward progress no matter what the plugin returns (?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We had a gdb stub returning {0, UINT64_MAX} the other week and it broke IRMemory::FindSpace() which will avoid any memory region with read/write/execute flags if qMemoryRegionInfo packets are supported. The stub claimed the entire address space, FindSpace() said it could not find any address range available, and all expressions broke.
Yeah, a range of {0, 1} would result in algorithms like FindSpace() looping for a very long time, and be nearly as bad. But so far the two instances I've seen of people return bad ranges are {0,0} and {0,UINT64_MAX}.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, but what's the alternative? Picking a piece of memory that may overlap with some existing data? It sounds to me like the stub gets exactly what it asked for.
True, but if we can change the expression to catch both, why not do it? What I'm suggesting is to change the expression into something like
if (GetRange().GetRangeBase() > addr || GetRange().GetRangeEnd() <= addr). The(0,0)case is subsumed by that, but this also catches any other incorrect response.Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see what you mean for checking the address is contained within the range, and rejecting it if not, this works too.
Right now if a stub returns {0, UINT64_MAX} and we don't have a memory allocation packet, IRMemory::FindSpace will find no available virtual address space and all expressions will fail.
My opposition to {0, UINT64_MAX} being accepted is that it's meaningless. No processor actually has 64-bits of virtually addressable memory, so telling me that all memory is addressable is obviously wrong. This response tells us nothing more than if qMemoryRegionInfo was an unsupported packet.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess the reason I don't like that is that it just feels like a very special case. Like if I send two regions, each covering half the address space, then I'm sort of saying the same thing, but unlike the single region, this response will get accepted. It also doesn't handle the case of a 32 bit address space being full. The fact that this breaks all of expression evaluation might be sort of a good thing actually, as it means the problem is likely to be caught.
If you feel strongly about this, then I don't want to stand in your way, but I would rather not have this special case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, your points make sense, thanks for sticking with this discussion. I'll update the patch as you suggest.