mirror of
https://github.com/ApfelTeeSaft/reactos.git
synced 2026-08-30 04:13:33 +00:00
[NTOS]: The fix above was due to fixing "EndingAddress" which was being initialized to zero too late (after writing to it!). This caused allocations with a fixed base address that were already on top of another allocation not to be seen as a conflict, then we tried inserting a VAD and received an ASSERT saying we've already found a VAD there. After fixing the sizing code, the bug above creeped up. Whoever wrote the NtFreeVirtualMemory test is a godsend. It has been nailing bug after bug in the VAD implementation. Thank you. svn path=/trunk/; revision=55990
RTL restrictions: ExAllocatePool (and friends) must be used exclusively. RtlAllocateHeap (and friends) must NOT be used! ExAllocatePool (and friends) translate to RtlAllocateHeap (and friends) in ntdll\rtl\libsupp.c. RtlEnterCriticalSection (and friends) must be used exclusively. ExAcquireFastMutex (and friends) must NOT be used! RtlEnterCriticalSection (and friends) translate to ExAcquireFastMutex (and friends) in ntoskrnl\rtl\libsupp.c. This means that RtlEnterCriticalSection (and friends) can NOT be used recursively in RTL. The reason for choosing RtlEnterCriticalSection (and friends) over ExAcquireFastMutex (and friends) is that the FAST_MUTEX struct is smaller than the RTL_CRITICAL_SECTION struct.