[llvm-bugs] [Bug 41690] New: SectionMemoryManager assumes allocateMappedMemory to return a size that is a multiple of page size, but it can return much larger memory blocks.

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=41690

            Bug ID: 41690
           Summary: SectionMemoryManager assumes allocateMappedMemory to
                    return a size that is a multiple of page size, but it
                    can return much larger memory blocks.
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: OrcJIT
          Assignee: unassignedbugs at nondot.org
          Reporter: contact at machiel.info
                CC: 1101.debian at gmail.com, llvm-bugs at lists.llvm.org

Recently, the behaviour of allocateMappedMemory in Memory.h was changed to
return the requested memory size in the returned MemoryBlock instead of the
size that was actually allocated. SectionMemoryManager was updated to assume
that allocateMappedMemory returns a memory block with a size that is a multiple
of the page size. This is a bad assumption because on windows
allocateMappedMemory returns sizes with a granularity of 64kb (16 pages).

This is currently causing huge memory consumption, as in 100s of MBs of wasted
space, and out-of-memory crashes in my use case (using the ORC JIT on Windows
in a 32-bit application).

Also, when protectMappedMemory in Memory.h is called on Windows, it will use
the size stored in the MemoryBlock, which now is the requested size, and not
the actual allocated size. This may cause problems if the extra available space
is actually used for executable code because the memory beyond the initially
requested size might not be given executable permissions. This is because the
allocation granularity is 16 pages and the memory protection granularity is 1
page on Windows. Therefore it is not enough to update SectionMemoryManager to
assume multiples of 64kb on Windows. It's probably better for a MemoryBlock to
expose both the requested size and the allocated size and for
protectMappedMemory to use the allocated size.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20190501/296e55b6/attachment.html>