[ros-kernel] Mm problem: "Freeing locked page"

[Hartmut Birr]

I'm running in the same problems.  

> -----Original Message-----
> From: ros-kernel-bounces at reactos.com 
> [mailto:ros-kernel-bounces at reactos.com] On Behalf Of Ge van Geldorp
> Sent: Wednesday, December 24, 2003 8:33 PM
> To: ros-kernel at reactos.com
> Subject: [ros-kernel] Mm problem: "Freeing locked page"
> 
> 
> When trying to run the AbiWord installer
> (http://prdownloads.sourceforge.net/abiword/setup_abiword.2-0-
> 2.exe?down
> load) I run into a problem: it bugchecks with the message "Freeing
> locked page" (mm/freelist.c 741). When tracking this down, I 
> found that
> the installer tries to ReadFile() something into a buffer which is
> located in the uninitialized data section (aka BSS). NtReadFile calls
> (via IoBuildSynchronousFsdRequest, IoBuildAsynchronousFsdRequest and
> IoPrepareIrpBuffer) MmProbeAndLockPages.
> MmProbeAndLockPages makes sure the buffer pages are paged in and then
> locks them. Next, it is checked whether write access is 
> required and if
> write access to the pages is already available. If not, 
> MmAccessFault is
> called to invoke the copy-on-write mechanism. Control is then
> transferred to MmAccessFaultSectionView, which allocates a 
> new physical
> page, copies the contents of the existing read-only page to 
> the new page
> and (in our case) locks the new page. A check is made if the current
> process is the only one interested in the old page and if so, 
> that page
> is released. Since this old page was locked in 
> MmProbeAndLockPages, this
> leads to the bugcheck.
> I tried to fix it with the attached patch (which unlocks the 
> old page if
> it is determined that the new page needs to be locked) and at 
> first that
> seemed to fix the problem. 

Your fix is correct. The same must be fixed at top of
MmAccessFaultSectionView.

> However, when execution of the 
> setup program
> continues, the system runs out of swap space ("MM: Out of 
> swap space.")
> and then bug checks again, trying to trim user memory, with the
> following stack trace:
> 
> KeBugCheck (BugCheckCode=0) at ke/bug.c:271
> MmPageOutSectionView (AddressSpace=0xc16151e8, MemoryArea=0xc161e590,
> Address=0x794000, PageOp=0xc15b8d90) at mm/section.c:1548
> MmPageOutPhysicalAddress (PhysicalAddress={u = {LowPart = 39084032,
> HighPart = 0}, QuadPart = 39084032}) at mm/rmap.c:307
> MmTrimUserMemory (Target=5, Priority=0, NrFreedPages=0xcdc09fd4) at
> mm/wset.c:55
> MiBalancerThread (Unused=0x0) at mm/balance.c:339
> 
> The bugcheck message is "Private page, non-dirty but not swapped out
> process 9 address 0x00794000". The (virtual) address 0x794000 
> is one of

This is possible a problem of the relocation code in ntdll. If the
loader canot load an image (program or dll) to its preferred load
address it must change many address in the read only code section. The
paging code for sections doesn't handle such a situation.

> the pages which was copied-on-write before, I've confirmed that the
> physical address is the physical address of the r/w page allocated by
> MmAccessFaultSectionView in the copy-on-write action.
> Looking at the code, I get the impression that the system is trying to
> tell me that there is a R/W page which is not backed by 
> paging file, but
> to be honest this is all a bit over my head. I would appreciate it if
> someone with better understanding of our MemoryManager could 
> take a look
> at it.
> Oh, BTW, this is all in VMware with 64Mb allocated to the virtual
> machine. Problem registered in Bugzilla as #102.

The out of swap space message comes possible from the page out code for
pagefile sections. If such a section is paged out, the page is not
freed. The problem is in MmUnsharePageEntrySectionSegment.
MmUnsharePageEntrySectionSegment must make a difference between deleting
and paging out a section. I've start to fixing this problem and
implementing shared dll sections. I've add a diff of my current changes.
To solve the out of memory problem, you should increase the page file to
32MB or more.

- Hartmut

 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: section.c.zip
Type: application/x-zip-compressed
Size: 3630 bytes
Desc: not available
Url : http://reactos.com:8080/pipermail/ros-kernel/attachments/20031228/46f6ba9b/section.c.bin