我一直在研究一个在
Windows XP嵌入式系统的应用程序中看到的一个相当难以捉摸的错误.
我们已将错误缩小到一个指向一个内存块的指针,而不是指向NULL.由于内存被分配了一个未被检查的malloc(..)的调用,我的直觉说malloc失败并返回NULL(尽管我们现在也在寻找其他可能性,例如可能会无意中更改指针).这是一个本机C应用程序.这次事故有点复杂,因为这个原因,主要是因为我们只有在不同的线程上没有来源的第三方库,因为我们只有死后的崩溃转储和失败.娱乐时间 :)
我的问题集中在内存耗尽的可能性.重要的是我们运行的XP Embedded系统的“pagefile”被禁用.
所以我有三个问题如果有人可以为我澄清这一点,那将是巨大的
>主要地,没有页面文件的影响是什么?这是否意味着当堆增长时,新内存需要由操作系统立即找到并分配,即使这些空闲块不立即使用?我已经看到了一些轶事,但是找不到关于什么效果禁用页面文件的具体内容.
>为什么微软决定在Windows Vista之前默认启用低分段堆?在Windows XP上启用LFH的过程是否有危险?
WinDbg在“外部碎片化”和“虚拟地址碎片”之间有什么区别?
WinDbg会在受影响的堆上报告堆统计信息,如下所示:
Heap Flags Reserv Commit Virt Free List UCR Virt Lock Fast
(k) (k) (k) (k) length blocks cont. heap
04770000 00001002 1621948 94844 1608284 102 6 8068 6 2 L
Virtual address fragmentation 94 % (8068 uncommited ranges)
解决方法
与Linux不同,Windows上的分配是一种承诺.您将能够写入分配的内存.性能可能是可怕的,但Windows不需要OOM杀手.
如果没有分页文件,则必须由RAM支持承诺.然而,未使用的存储器(例如仅在程序初始化期间使用的存储器)仍然使用RAM,因为它不能被分页.所以有更少的内存来做出承诺,但需要更大的需求.
LFH打破了错误的程序,或更好地说明:错误的程序可能会在LFH的情况下显示他们的错误.微软对破坏程序非常友好,并且使LFH选择XP是其适应行为的典型例子.