Reading unmapped memory is not a crime? #8906
Replies: 2 comments 6 replies
-
|
Hmmm, am going to guess this is a bug, but not one I understand at the moment. Generally, "red" means it couldn't read the memory or didn't try because that memory didn't exist in any known region. Assuming "Force Full map" was on, the latter shouldn't be the case. Might be a caching or synchronization issue, but I would have thought it would have shown up greyed out versus red. I'll discuss this with @nsadeveloper789 - probably Tuesday (snow and what not here). You probably have more context, but I wouldn't have guessed device-mapped memory and shared memory is typically readable for the debugger. If you read the same memory at the same point from lldb proper (no Ghidra), do you get valid bytes? If no, your theories are still in play. If yes, am going with a bug in our code. |
Beta Was this translation helpful? Give feedback.
-
|
OK, well, that's evidence in favor of your other theories, but still a little unclear as to the base cause. The terminal in Ghidra is a pretty thin wrapper on the lldb repl. Am guessing a bare lldb experiment will yield the same results. And am guessing a command-line read of the memory after that instruction was executed would succeed, at least in the local case. Lldb's behavior in the remote case is a little different than the local case, particularly with regard to caching, as I understand it. Presumably, stepping clears this cache, so, even if the initial read from ghidra/lldb causes the memory to be paged in, you may not see the memory marked as valid until the cache gets cleared and a new read is executed. You can also try forcing a cache flush with |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Sorry, this question is not really about Ghidra (or maybe it is), but about debugging aarch64.
I have the following code in my binary:
x2is78e6a39018When I am going to
0x78e6a39018in "Dynamic", I am getting it all highlighted with red, and, seemingly, uninitialised/unmapped:BUT
Stepping through this instruction works!
When I am stepping to the next instruction, I am not getting a crash, and the value in
d1is not 0, but208020d020d020f.What is going on? Is this a bug? If yes, then in what? In Ghidra? In lldb? In Android?
If this is not a bug, then what is it? A device-mapped address unavailable to a debugger? A shared memory piece unavailable to a debugger?
How do I debug such cases?
Sorry if this is not entirely Ghidra-related, but perhaps I am missing something completely obvious, but this really seems mysterious, and I hope that future Ghidra users stumbling upon this question might find it useful.
Beta Was this translation helpful? Give feedback.
All reactions