Memory 这是内存地址吗？

我正在学习gdb，我犯了第一个错误。这就是错误：

0x00007fff83074096 in __kill ()

地址：

0x00007fff83074096

---

。。。十六进制格式的内存地址？出于兴趣，我把它转换成十进制，这个数字很大。我不相信存在这么多内存地址。

如果您运行在64位平台上，那么是的，存在这么大的地址。（另见：）

当然，有可能只是某个地方发生了缓冲区溢出，从而损坏了堆栈，并用无意义的内容覆盖了地址。

是的。是的

它是64位进程虚拟内存空间中的地址

并非所有地址都在使用中（这就是地址的含义：它只是一个标签）

您可以通过执行以下操作查看有关地址的更多信息

:break 0x00007fff83074096
:list 0x00007fff83074096
:disassemble 0x00007fff83074096

看到了整个堆栈吗

 :bt full

在所有线程中

 :thread apply all bt full

---

16个十六进制数字x 4（由一个十六进制数字表示的位）=64位。您使用的是64位平台，为什么感到惊讶？

是的，它是一个内存地址。由于，有比实际内存多得多的内存地址可用于支持虚拟地址空间

---

您可能会发现运行

pmap-x 1

或

pmap-x$$

以及查看不同进程的

/proc/pid/maps

内容很有帮助。（

cat/proc/self/maps

很容易运行。）

…您是否在64位模式下运行它？为什么是-1？这是一个真正的问题。我在上计算机科学课程，只是在学习。我见过十六进制的内存地址，但没有接近那个大的地址，这就是为什么我问它的格式。@Matti我正在运行一个新的MacBookPro。我认为它是64位的。有趣的是，当地址明显超过32位容量时，人们会问系统是否是64位的……不要担心-1，这些桥下有很多巨魔。他们喜欢出来给-1，然后回去，而不给社区任何有价值的投入。这让他们觉得自己很强大。缓冲区溢出显然与此无关——GDB将地址解析为_kill。@Employed:那么你怎么知道缓冲区溢出没有覆盖堆栈上的返回地址，并且我们没有被随机抛出到这个函数中？我知道这一点，因为崩溃地址不是（通常情况下）位于堆栈上——它直接来自内核。当您看到堆栈损坏时，总会得到正确的崩溃点（在过去15年中我看到的每个UNIX系统上）。您只是看不到调用堆栈的其余部分。尝试一个破坏堆栈的测试用例，自己看看。这里有一个可以让您省去键入：void foo（）{char buf[1]，*p=buf；而（p）{*p++='a'；}}}int main（）{foo（）；return 0；}