时间戳

首页 > 解决方案 > 为什么我没有收到分段错误？

c - 为什么我没有收到分段错误？

问题描述

我有 

x=(int *)malloc(sizeof(int)*(1));

但我仍然能够阅读x[20]或x[4]。

我如何能够访问这些值？我不应该在访问这些内存时遇到分段错误吗？

标签： cmallocdynamic-memory-allocation

解决方案

基本前提是 Sourav Ghosh 的回答：访问从 malloc 返回的超出您要求的大小的内存是未定义的行为，因此允许符合要求的实现几乎可以做任何事情，包括愉快地返回奇怪的值。

但是考虑到“正常”机器（gcc/MSVC/clang、Linux/Windows/macOS、x86/ARM）上的主流操作系统上的“正常”实现，为什么有时会出现分段错误（或访问冲突），有时却不会？

几乎每个“常规”C 实现在通过指针1读/写时都不会执行任何类型的内存检查；这些加载/存储通常直接转换为相应的机器代码，该机器代码访问给定位置的内存，而不考虑“抽象 C 机器”对象的大小。

然而，在这些机器上，CPU 并不直接访问 PC 的物理内存 (RAM)，而是引入了转换层 (MMU) 2；每当你的程序试图访问一个地址时，MMU 会检查那里是否映射了任何东西，以及你的进程是否有权限写入那里。万一这些检查中的任何一个失败3，您会遇到分段错误并且您的进程会被终止。这就是为什么未初始化和NULL指针值通常会给出很好的段错误：虚拟地址空间开头的一些内存被保留未映射只是为了发现NULL取消引用，一般来说，如果您将 dart 随机放入 32 位地址空间（或者更好的是 64 位地址空间），您最有可能找到从未映射到任何内容的内存区域。

尽管它很好，但由于多种原因，MMU 无法捕获所有内存错误。

首先，与大多数“普通”分配相比，内存映射的粒度相当粗糙；在 PC 上的内存页（可以映射并具有保护属性的最小内存单元）的大小通常为 4 KB。这里当然有一个折衷：非常小的页面本身需要大量内存（因为每个页面都有一个目标物理地址和保护属性，并且这些属性必须存储在某个地方）并减慢 MMU 操作3。因此，如果您访问“逻辑”边界之外的内存但仍在同一内存页面内，则 MMU 无法帮助您：就硬件而言，您仍在访问有效内存。

此外，即使您超出了分配的最后一页，就硬件而言，后面的页面也可能是“有效的”；事实上，这对于你从所谓的堆（malloc&朋友）获得的内存来说是很常见的。

这是因为malloc，对于较小的分配，不会向操作系统询问“新”内存块（理论上可以分配在两端保持保护页）；相反，C 运行时中的分配器以大的顺序块向操作系统请求内存，并在逻辑上将它们划分为较小的区域（通常保存在某种链接列表中），这些区域malloc由free.

现在，当您在程序中超出所请求内存的边界时，您可能不会收到任何错误，因为：

  • 您正在使用的内存块不在页面边界附近，因此您的越界读取不会触发访问冲突；

  • 即使它在页面的末尾，后面的页面仍然被映射，因为它仍然属于堆；它可能是分配给进程的其他代码的内存（因此您正在读取代码中某些不相关部分的数据），也可能是空闲内存区（因此您正在读取前一个进程留下的任何垃圾）块的所有者free），或分配器用来保存其簿记数据的区域（因此您正在读取此类数据的一部分）。

    在所有这些情况下，除了“空闲块”之外，即使你在那里写，你也不会遇到分段错误，但你可能会破坏不相关的数据或堆的数据结构（这通常会导致以后崩溃，因为分配器在其数据中发现不一致）。

笔记

  1. 尽管现代编译器提供了特殊的检测构建来捕获其中一些错误；尤其是 gcc 和 clang，提供了所谓的“地址清理器”。
  2. 这允许引入透明分页（在物理内存可用性低的情况下交换到未主动使用的磁盘内存区域），最重要的是，内存保护和地址空间分离（当用户模式进程运行时，它“看到“一个完整的虚拟地址空间，只包含他的东西，没有来自其他进程或内核的任何东西）。
  3. 并且通知进程正在尝试访问已换出的内存并不是操作系统故意放在那里的故障。
  4. 鉴于每次访问内存都需要经过 MMU，映射必须非常快，所以最常用的页映射保存在缓存中；如果您使页面非常小并且缓存可以容纳尽可能多的条目，那么缓存覆盖的内存范围实际上会更小。

推荐阅读