c - OSDev:为什么我的内存分配功能突然在AHCI初始化功能中停止工作？

Question

在我的内核调用ArchInit（）函数内部的AHCIInit（）函数之后，我在其中一个MemAllocate（）调用中遇到了页面错误，并且这仅在真实计算机中发生，因为我尝试在VirtualBox，VMWare和QEMU上复制它。

我尝试调试代码，对内存分配器进行单元测试，并从内核中删除所有内容，但内存管理器和AHCI驱动程序本身除外，我发现的唯一发现是某些东西破坏了分配块，使MemAllocate（ ）页面错误。

整个内核源位于https://github.com/CHOSTeam/CHicago-Kernel，但是可能出现问题的主要文件是：
https://github.com/CHOSTeam/CHicago-Kernel/blob/master/mm/alloc.c
https://github.com/CHOSTeam/CHicago-Kernel/blob/master/arch/x86/io/ahci.c

我希望AHCIInit（）能够检测并初始化所有AHCI设备，并且引导继续进行到到达会话管理器或内核外壳为止，但是在实际计算机中，它甚至在初始化调度程序之前也会出现页面错误（因此，问题不在于“我的调度程序）。

Answer 1

如果它可以在模拟器中运行，但不能在实际硬件上运行；那么我首先想到的是：


物理内存管理中的错误。例如，物理内存管理器初始化未将“可用RAM区域的起始地址”四舍五入到页面边界，或者未将“可用RAM区域的结束地址”四舍五入到页面边界，从而导致“一半的可用RAM和一半的不可用RAM”。 ”页面，稍后由堆分配（该页面可在模拟器上运行，因为固件提供的内存映射恰好描述了无论如何对齐的区域）。
一个假定RAM包含零但可能不包含零的错误（它在仿真器上起作用，因为它们倾向于使几乎所有RAM都充满零）。
竞赛条件（不同的计时导致不同的行为）。


然而;这是一个整体式内核，这意味着您将不断面对“内核空间中的任何代码都做了某些事情，这些问题导致其他地方的任何其他代码出现问题”；并且存在很多与内存使用有关的错误（例如，意外地在分配的内容写完之后）。因此，我希望有更好的工具来帮助诊断问题，尤其是对于堆。

具体来说，对于堆，我将从金丝雀开始（例如，在堆中的每个内存块之前放置一个魔术数字，如0xFEEDFACE，在堆中的每个内存块之后放置另一个不同的数字；然后检查幻数是否仍然在方便的地方显示并纠正-例如，释放或调整块的大小。然后，我将编写一个“ check_heap（）”函数，该函数将尽可能多地检查所有内容（金丝雀，如果“空闲块数”之类的统计信息实际上是正确的，等等）。这样的想法是（无论何时您怀疑某个东西可能破坏了堆），您都可以插入对“ check_heap（）”函数的调用，并移动该调用，直到找出导致片断损坏的代码。我还建议在您的“ kmalloc()或等效项”中使用一个“ what”参数（例如，您可以执行myFooStructure = kmalloc("Foo Structure", sizeof(struct foo));之类的操作），其中所提供的“ what string”存储在分配的块的元数据中，这样，以后（当您发现堆已损坏时）就可以在损坏之前显示与该块关联的“字符串”，以便您可以（例如）列出当前要处理的每种类型的事物有多少个。帮助确定什么正在泄漏内存（例如，“ Foo Structure”块的数量是否不断增加）。当然，可以通过编译时选项（例如#ifdef DEBUG_HEAP）启用/禁用这些功能。

我推荐的另一件事是自测。这些就像单元测试一样，但是直接内置在内核本身中并且始终存在。例如，您可以编写代码以将日光从堆中取出（例如，分配随机大小的内存，并用一些东西填充它们，直到耗尽内存，然后释放一半的内存，然后分配更多的内存，直到耗尽内存）再次，依此类推；在每个步骤之间调用“ check_heap（）”函数时）；该代码可以/应该采用“多少磅”参数的位置（因此您可以花费少量时间进行自检，也可以花费大量时间进行自检）。您还可以编写代码以消除虚拟内存管理器和物理内存管理器（以及调度程序等）的日光。然后，您可以决定每次启动内核时总是进行少量的自测试，并且/或者提供一个特殊的内核参数/选项以启用“极端彻底的自测试模式”。

不要忘记，最终（如果/发布操作系统时）您可能不得不求助于“通过电子邮件进行远程调试”（例如，没有任何编程经验的人，可能不太懂英语，会给您电子邮件中说“操作系统不起作用”；您必须设法弄清楚出了什么问题，然后最终用户的“放弃和不再关心之前的麻烦”计数器将耗尽。