GDB:如何查看哪些内存地址是可访问的?

发布于 2024-09-24 00:23:58 字数 300 浏览 5 评论 0 原文

假设在调试会话中我有一个不幸地指向一些垃圾的地址。我想检查它周围的记忆,看看附近有什么。正如预期的那样,出现以下错误:

(gdb) x/64 $t5
0x842da7ac:     Cannot access memory at address 0x842da7ac

那么,问题是:有没有办法读取一系列地址,其中一些地址无效?

(更准确地说,我如何知道上面的示例中的 $t5+n 是某些 0 的有效地址?)

Suppose, in a debugging session I have an address which unfortunately points to some rubbish. And I want to examine memory around it to see what's located near. As expected, the following error occurs:

(gdb) x/64 $t5
0x842da7ac:     Cannot access memory at address 0x842da7ac

So, the question is: is there any way to read a range of addresses, some of which are not valid?

(More precise, how can I know that in the example above $t5+n is a valid address for some 0 < n <= 64?)

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

你与昨日 2024-10-01 00:23:58

您无法读取无效地址(显然)。

在某些操作系统上,当进程在 GDB 中停止时,您可以查询操作系统有关有效地址的信息。例如,在 Linux 上,cat /proc//maps 将为您提供有关哪些地址有效(以及它们有效的访问模式)的信息。其他操作系统可能具有类似的机制。

由于您将问题标记为事后分析,因此您无法使用上述机制;但你必须有一个 core 文件。在 Linux(和其他 ELF 系统)上,readelf -l core 会告诉您哪些内存区域被写入核心,这通常可以让您很好地了解哪些内存在崩溃时有效。但是,只读映射通常不会写入 core,因此您可能在 readelf 输出中看不到此类映射。

所有现代操作系统都使用分页,并且页面至少为 1K(尽管 4K 更常见),因此您可以知道最接近 $t5 的内存code> 可能有效的是 0x842da800,因此 n >= 84(字节)。

最后,如果你要求GDB检查64个单词,而GDB无法检查第一个单词,它就会停止。

但是,如果您使用的是 GDB-7.x,则可以要求 GDB 在 Python 中一次检查一个单词,如果 GDB 无法检查该特定单词,则会抛出 Python 异常。但既然你可以捕获Python异常,那么编写一个脚本来实现“检查接下来的N个单词,忽略任何不可读的单词”在Python中是微不足道的(我相信这回答了你的“如何做到这一点”的问题)。

You can't read invalid addresses (obviously).

On some OSes you can can query the OS about valid addresses while the process is stopped in GDB. For example, on Linux cat /proc/<pid>/maps will give you info about which addresses are valid (and the access mode they are valid for). Other OSes may have similar mechanism.

Since you tagged your question post-mortem, you can't use above mechanism; but then you must have a core file. On Linux (and other ELF systems), readelf -l core will tell you which regions of memory were written into the core, which usually gives you a good idea of what memory was valid at the time of crash. However, read-only mappings are usually not written to core, so you may not see such mappings in readelf output.

All modern OSes use paging, and pages are at least 1K (though 4K is more common), so you can tell that the closest memory to $t5 which could possibly be valid is 0x842da800, and so n >= 84 (bytes).

Finally, if you ask GDB to examine 64 words, and GDB can't examine the first one, it will stop.

However, if you are using GDB-7.x, you can ask GDB to examine one word at a time in Python, and GDB will throw Python exception if it can't examine that particular word. But since you can catch Python exceptions, it is trivial to write a script that will implement "examine next N words, ignoring any unreadable ones" in Python (which I believe answers your "how can this be done" question).

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文