OSDev.org

Posted: **Sat Aug 29, 2009 4:19 pm**

Hi everyone!

I've been stuck for a while trying to figure out why some code I have isn't working. The basic idea of things is that we get a page fault when trying to read a MemoryMappedFile. This traps, and ideally the relevant section of the file would be read into memory. This works well, but I've run into a roadblock now that makes little sense. There's a deterministic error that occurs on the second application load. execve() wipes all previous (non-anonymous) memory mapped files from memory, so there's a set of unmappings performed in the address space. These pages are now free to allocate, so the new application gets given the old application's region (it's smaller).

This is all well and good. The read traps, and the mapping function gets called. This detects two things: first, the page table isn't present (and allocates it), and then that the page to be mapped isn't present (so maps it). Normally this works flawlessly, but in this one case, no amount of TLB flushes, flag manipulation or checks can actually get the page mapped - I will always get a page fault.

My biggest problem is that this only occurs on my Windows development environment: nobody else on the team has this problem, and I don't see it if I use a Linux virtual machine as a host. Yet it will do it on Bochs and QEMU, without fail.

Any ideas?

Posted: **Sun Aug 30, 2009 12:56 am**

In your x86 paging code, you have page tables permanently mapped in (by pointing a PDE to the page directory). In X86VirtualAddressSpace::revertToKernelAddressSpace, you clear out old pages and page tables, however when you clear the page directory entry to remove a page table, you don't invalidate the TLB entry for the virtual address that maps that page table in, so later if a new page table is mapped in, the TLB entry for the virtual page table address may still point to the old page table that was mapped there.

Seeing this makes it seem pretty certain that this is the problem:

Code: Select all

/// \note I'm now getting a page fault during execve (MemoryMappedFile::trap) that occurs only
///       when these lines are kept in. I've left them here because they're correct. - Matt
// PhysicalMemoryManager::instance().freePage(PAGE_GET_PHYSICAL_ADDRESS(pageDirectoryEntry));
// *pageDirectoryEntry = 0;

Posted: **Sun Aug 30, 2009 5:12 am**

That's the problem, thanks AlexExtreme!

I guess that's what happens when you look at a problem for too long - you begin missing the blatantly obvious answers

OSDev.org

Paging on the x86: My Mapping Isn't Working!

Paging on the x86: My Mapping Isn't Working!

Re: Paging on the x86: My Mapping Isn't Working!

Re: Paging on the x86: My Mapping Isn't Working!