summaryrefslogtreecommitdiff
path: root/EdkCompatibilityPkg/EdkCompatibilityPkg.dsc
diff options
context:
space:
mode:
authorjgong5 <jgong5@6f19259b-4bc3-4df7-8a09-765794883524>2010-04-03 05:34:16 +0000
committerjgong5 <jgong5@6f19259b-4bc3-4df7-8a09-765794883524>2010-04-03 05:34:16 +0000
commit38c7df9848811c2a6e6ed11fd78ba0e19215e77c (patch)
tree34ca11409ada76da89f8634c56b1e5e79d81b1fe /EdkCompatibilityPkg/EdkCompatibilityPkg.dsc
parent969eba7b0df70c9aa261eaf005085568b88de87c (diff)
downloadedk2-platforms-38c7df9848811c2a6e6ed11fd78ba0e19215e77c.tar.xz
Avoid DEBUG_CLEAR_MEMORY clearing MemoryMap internal structure.
In CoreFreePages(), the following sequence might break the MemoryMap internal structure: CoreConvertPages() -> CoreFreeMemoryMapStack() -> AllocateMemoryMapEntry() -> CoreAllocatePoolPages() -> DEBUG_CLEAR_MEMORY() CoreConvertPages() will call CoreFreeMemoryMapStack() after it adds the freed memory range, so the latter might use the just freed memory range when calling AllocateMemoryMapEntry(). But CoreFreePages() will call DEBUG_CLEAR_MEMORY() after CoreConvertPages(). This might clear up the memory map entry structure. The fix calls DEBUG_CLEAR_MEMORY() just after freed memory range is added in CoreConvertPages(), which is safe. git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@10335 6f19259b-4bc3-4df7-8a09-765794883524
Diffstat (limited to 'EdkCompatibilityPkg/EdkCompatibilityPkg.dsc')
0 files changed, 0 insertions, 0 deletions